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A Symposium on High-Performance Chips 



HOT Chips IV 


Stanford University , Stanford , California 
August 9-11, 1992 


CALL FOR CONTRIBUTIONS 

HOT CHIPS is back once again! Sponsored by the IEEE Computer Society Technical Committee on 
Microprocessors and Microcomputers, Hot Chips IV is a conference that consists of presentations on 
high-performance chip and chip-set products, and related topics. This conference is directed particularly 
at new and exciting products. The emphasis is on real products, not academic designs. Participants will 
not be required to prepare written papers. The proceedings will consist of copies of the slides to be 
presented. 


Contributions are solicited in the following areas: 


• RISC and CISC Processors 

• Floating Point Processors 

• Embedded CPUs 

• Graphics & Image Processing Chips 

• Digital Signal Processors 

• Network Chip-Sets 


• Bus Chips 

• Cache Controllers and Memories 

• Neural Chips 

• Systolic Array Chips 

• Compiler Issues with Hot Chips 

• Benchmarking/Performance Evaluation 


Proposals should consist of a title, an extended abstract (1-5 pages) describing the product or topic to 
be presented, and the name, title, address, phone number, fax number, and electronic mail address of 
the presenter. If this is a not-yet-announced product, and you would like the submission kept confiden¬ 
tial, please indicate it; we will do our best to maintain confidentiality. Submissions can be made by hard 
copy, fax, or electronic mail by Friday, March 6, 1992 to: 

Bob Miller Office: (510) 642-6037 

University of California, Berkeley Fax: (510)642-5775 

Computer Science Division Email: bmiller@ginger.berkeley.edu 

533 Evans Hall 
Berkeley, CA 94720 

For further general information about the symposium, contact Glen Langdon at (408) 459-2212 or 
langdon@cse.ucsc.edu. For further information about submissions, contact Bob Miller at (510) 642-6037 
or bmiller@ginger.berkeley.edu. 


General Chair 

Glen Langdon 
UC Santa Cruz 


Program Co-Chairs 

David Patterson, UC Berkeley 

John Mashey, MIPS Computer Systems 
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Realistic simulation of your network or embedded computer 
system-quick results, no programming 
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NETWORK II.5 now predicts performance of 
computer-communication systems 

Free trial and, if you act now, free training 


N etwork 11.5 uses 

simulation to predict your 
network performance. You simply 
describe your network and work¬ 
load. 

Animated simulation follows im- 
mediately~no programming delays. 

Easy-to-understand results 

You get an animated picture of 
your network. System bottlenecks 
and changing levels of utilization 
are apparent. 

Seeing your network animated in¬ 
creases everyone’s understanding of 
its operation and builds confidence 
in your results. 

Your reports show response 
times, messages delivered, messages 
lost, device utilization, and queue¬ 
ing statistics. 

Computers with NETWORK II.5 

NETWORK II.5 is available for 
most PC’s, Workstations, and 
Mainframes. 


Your network simulated 

You can analyze embedded or 
distributed computer systems, or 
other computer-communication net¬ 
works. Industry standard protocols 
such as FDDI and IEEE Standard 
802.X are built-in. Others can be 
modeled. 

You can easily study the effect of 
changing network parameters or 
even network protocols. 

You can simulate some portions 
of the network at a detailed level 
and others at a coarser level. 

Free trial information 

The free trial contains everything 
you need to try NETWORK II.5® 
on your computer. For a limited 
time we also include free training 
-no cost, no obligation. 

Call Paul Gorman at (619) 

457-9681, Fax (619) 457-1184. In 
Europe, call Nigel McNamara, in 
the UK, on 0276 671 671, Fax 0276 
670 677. In Canada, call Peter Holt 
on (613) 782-2474, Fax (613) 

782-2202. m!r^CAa' 5 pjodV/tfcom d an ademark a " d 


Free trial offer 

I DYes I want to see how NETWORK 11.5 
quickly answers network performance 
questions. 

Limited offer—Act now for free training. 


□ Send details on your University Offer. 

Return to: Mie comp 

CACI Products Company 
3344 North Torrey Pines Court 
La Jolla, California 92037 

Call Paul Gorman at (619) 457-9681 
Fax (619) 457-1184 
In Europe: 

CACI Products Division 
Coliseum Business Centre 
Watchmoor Park, Riverside Way 
Camberley, Surrey GU15 3YL, UK 

Call Nigel McNamara on 0276 671 671 
Fax 0276 670 677 
In Canada: 

CACI Products Company 
200-440 Laurier Avenue West 
Ottawa, Ontario KIR 7X6 

Call Peter Holt on (613) 782-2474 
Fax (613) 782-2202 
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LETTERS TO THE EDITOR 


We can’t please everyone 


To the Membership/Circulation 
Manager: 

It is with some regret that I write to 
inform you that I will not be renewing 
my membership in the IEEE Comput¬ 
er Society. Unfortunately, it appears 
that both the IEEE Computer Society 
and ACM are continuing their trend 
of moving away from support of those 
of us in colleges and universities who 
are most interested in issues relating 
to current research and college-level 
teaching. This seems to be an inevita¬ 
ble effect of the attempt to broaden 
the membership in these organiza¬ 
tions. However, the result is that your 
publications have less and less interest 
to me. Your focus, as expressed in 
many editorials and other communica¬ 
tions, is instead on publishing articles 
which will be of direct and immediate 
value to practitioners working on soft¬ 
ware and hardware development. This 
seems to be a necessary by-product of 
your attempt to retain the interest of 
this broader membership. 

The result for me, however, is a 
much less interesting set of journals. 

In particular, IEEE Software used to 
publish survey articles which were 
highly relevant to me and my stu¬ 
dents. They discussed recent research 
in a way which made it accessible to a 
larger audience. Unfortunately, I see 
much less of that today, and judging 
by recent editorials, there will be even 
less of it in the future. 

Since ACM has adopted a similar 
strategy, I find myself belonging to 
two organizations whose goals are be¬ 
coming less relevant to mine. Under 
these circumstances, I have decided 
that I will retain only one of these two 
memberships. I have chosen to retain 
my ACM membership rather than 
that of the IEEE Computer Society 
because they place a bit more empha- 


Computer welcomes your letters. 
Send to Letters Editor, Computer, 
10662 Los Vaqueros Circle, PO 
Box 3014, Los Alamitos, CA 90720- 
1264. 

All submissions are subject to 
editing for style, length, and clarity. 


sis on the computer science (rather 
than computer engineering) aspects of 
computing (which reflects my inter¬ 
ests), and because they place less em¬ 
phasis on standardization activities as 
a primary goal. 

I should add that I have been ac¬ 
tively involved over the last several 
years as an ACM representative on 
two joint ACM/IEEE Computer Soci¬ 
ety committees on educational activi¬ 
ties (the most recent being the Joint 
Curriculum Task Force). However, I 
find the increased focus of both soci¬ 
eties over the last several years on ac¬ 
creditation to be a distraction from 
more important educational issues. In 
particular, we should be more inter¬ 
ested in fostering innovation than in 
stressing the importance of bean 
counting as a means of assessing edu¬ 
cational quality. For example, I was 
disturbed by the role that accredita¬ 
tion requirements played in the delib¬ 
erations of the Joint Curriculum Task 
Force, whereas the work of the Task 
Force should have influenced accredi¬ 
tation requirements. 

So as not to be completely negative, 
I should note that I personally find 
the research conferences sponsored 
by the two organizations to be ex¬ 
tremely valuable. It is the perceived 
focus of the flagship periodicals and 
the organizations themselves that I 
find troubling. 

I believe the ultimate solution is the 
creation of a separate society devoted 
to the needs of researchers and faculty 
in computing. The needs of practitio¬ 
ners and researchers are too disparate 
to be well-served by one society. 

Kim B. Bruce 

Williams College 

Williamstown, Massachusetts 


To the Vice President for Member¬ 
ship Activities: 

Thank you for inviting me to rejoin 
the Computer Society; I would very 
much like to be a member. I run a 
consulting company that produces 
custom software for various customers 
nationwide and am one of the individ¬ 
uals who relies on his talents to create 
working software products every year. 


Several of the products I developed 
have been reviewed positively in vari¬ 
ous Computer Society publications. 

Unfortunately the Computer Soci¬ 
ety has become so focused on academ¬ 
ic publication that for the year before 
I let my membership lapse, I did not 
see a single article I was interested in 
reading. While all of your authors 
have impressive research credentials, 
many of them have little experience 
actually making programs work, and 
the articles reflect this. 

I would suggest the following 
changes would make Computer much 
more useful for practicing software 
engineers: 

(1) Condense the current articles 
into single-page summaries and 
leave the publication of full pa¬ 
pers for the transactions. 

(2) Add summary lists of new avail¬ 
able software tools. 

(3) Provide in-depth evaluations of 
various software tools. 

(4) Solicit articles that actually dis¬ 
cuss software creation, like: 

• How much does it currently 
cost to develop software? 

• What difficulties are involved 
in contracting software out? 

• What are some good team 
organization and manage¬ 
ment techniques? 

• What are software testing ex¬ 
pectations for commercial 
products? Not “cyclomatic” 
complexity, etc. Please! 

(5) In the absence of this type of 
sweeping change in editorial fo¬ 
cus, how about even a single 
monthly column devoted to 
software development issues? 

(6) How about a software develop¬ 
er’s forum? 

I recognize that there needs to be a 
respected forum for academic publica¬ 
tion, and Computer in its current form 
is important. But the IEEE also really 
needs at least one publication for 
practicing software engineers. When 
you have one, please let me know; I’d 
love to renew my membership. 

Charles J. Simon 

Abtek Computer Corporation 

Spokane, Washington 
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But, with your help, 
we try 

Our readership surveys indicate 
that members want and need practi¬ 
cal, immediately usable material in 
[ Computer Society magazines — but 

not necessarily to the exclusion of the¬ 
oretical and research topics. Deter¬ 
mining the proper mix is a difficult 
call, and we obviously miss in some 
cases, like the two at left, where indi¬ 
vidual needs are widely different. 
That’s why, in addition to Computer, 
we publish six specialty magazines 
and five transactions. And, we’re hap¬ 
py to report, Charles Simon is con¬ 
tinuing his membership now that 
we’ve told him about IEEE Software 
and how it meets the needs of practic¬ 
ing software engineers. 

How are we doing at meeting your 
needs? Please let us know via the RS 
Card on page 104A by circling the ap¬ 
propriate numbers for our mini reader 
survey below. 

Computer articles are 

161 Too research-oriented 
and theoretical for me 

162 Just right 

163 Not practical enough to 
have immediate value 

The type of articles I prefer are 

164 Tutorials 

165 Surveys 

166 Detailed reports 

The best article length is 

167 Short: Under seven 
pages with up to 10 
articles per issue 

168 Medium: Eight to 12 
pages with six to eight 
articles per issue 

169 Long: Over 12 pages 
with only five articles 
per issue 

If you have specific comments, 
please use the space under “Editorial 
comments” on the RS card. 

—Ed. 


National University of 
Singapore 

Department of Electrical Engineering 

Appointments 

The Department of Electrical Engineering invites applications for teaching and 
research appointments from candidates with a PhD degree in one of the following 
areas: 

• Computer Communications 

• Optical Fibre Communications 

• Computer Architecture and Systems 

Besides appointments on normal 3-year contracts, visiting appointments for 
one to two years may be considered. 

Gross annual emoluments range as follows: 

Research Scientist/Lecturer S$53,160 - 64,200 
Senior Lecturer S$58,680 -100,310 

Associate Professor S$88,650 -122,870 

(US$1.00 = S$1.67 approximately) 

The commencing salary will depend on the candidate’s qualifications, experi¬ 
ence and the level of appointment offered. 

Leave and medical benefits will be provided. Depending on the type of contract 
offered, other benefits may include: provident fund benefits or an end-of-contract 
gratuity, asettling-in allowance of S$1,000 or S$2,000, subsidized housing at nom¬ 
inal rentals ranging from S$100 to S$216 p.m., education allowance for up to three 
children subject to a maximum of S$16,000 per annum per child, passage assis¬ 
tance and baggage allowance for the transportation of personal effects to 
Singapore. Staff members may undertake consultation work, subject to the ap¬ 
proval of the University, and retain consultation fees up to a maximum of 60% of 
their gross annual emoluments in a calendar year. 

Lee Kuan Yew Postdoctoral Fellowship 

Applicants for appointments as Research Scientist may also apply for the Lee 
Kuan Yew Postdoctoral Fellowship, which will be awarded to candidates with ex¬ 
cellent academic records and research potential and who had obtained their PhD 
degrees in the last few years. A tax-free stipend will be provided under the Fellow¬ 
ship which will be held concurrently with the candidate’s appointment as a 
Research Scientist. 

Facilities 

The Electrical Engineering Department has currently an academic staff of 53 
with 21 laboratories, all of which have excellent facilities for teaching and re¬ 
search. In addition, there are two externally funded research centres: Centre for 
Optoelectronics and Centre for IC Failure Analysis and Reliability. Facilities in¬ 
clude a Riber 32P Molecular Beam Epitaxy System and 2 liquid phase expitaxy 
systems for research into in —V compound devices. A wide range of computing 
resources are available, including numerous PCs, SUN Sparcstations, Microvaxes, 
and HP 9000 Series 300s. The University Computer Centre operates an IBM3081 
KX2, and has acquired a high-speed campus-wide network directly linking the 
staff’s PCs (now provided to every staff member) to the various computing re¬ 
sources, including 2 supercomputers based in the nearby Science Park. A number 
of large-scale research projects are in progress, including an optical LAN joint ef¬ 
fort with Singapore Telecoms and a project to develop VLSI design tools jointly 
with Chartered Semiconductors. 

Application forms and further information on terms and conditions of service 
may be obtained from: 

The Director The Director 

Personnel Department North America Office 

National University of Singapore National University of Singapore 
10 Kent Ridge Crescent 55 East 59th Street 

Singapore 0511 New York, NY 10022 USA 

Tel: (212) 751-0331 

Enquiries may also be sent through BITNET to: PERLCH@NUS3090, or through 
Telefax: (65) 7783948. 
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International ParaM 
Processing Symposium 


Join us March 23-26, 1992 at 
The Beverly Hilton in Beverly 
Hills, California. 

The 6th International Parallel 
Processing Symposium will 
offer an exciting program 
covering all aspects of parallel 
and distributed processing. 
This year, the IEEE Computer 
Society is sponsoring the 
event in cooperation with the 
ACM SIGARCH and the 
Computer Society’s Orange 
County Chapter. 

Over 350 papers were 
submitted and include work of 
researchers from all around 
the world. The papers 
selected will be presented in 
21 sessions. 

In addition, IPPS ‘92 will 
present tutorials, a workshop 
on heterogeneous processing, 
and a parallel systems fair. 


Program Chair 

Viktor K. Prasanna, USC 

Program Committee 

Dharma Agrawal, North Carolina 

State University 

Lubomir Bic, UCI 

Mary Eshaghian, NJIT 

Kai Hwang, USC 

Oscar Ibarra, University of 

California, Santa Barbara 

Joseph Ja’Ja’, University of 

Maryland 

Lennart Johnsson, Thinking 

Machines Corporation & Harvard 

University 

H. T. Kung, CMU 

Louis Lome, SDI/ISTO 

L. M. Patnaik, Indian Institute of 

Science 

Thomas Probert, Encore Computer 
Corp. 

John Reif, Duke University 
Sartaj Sahni, University of Florida 
J. L. C. Sanz, IBM Almaden 
Research Center 
H. J. Siegel, Purdue University 
Harold Stone, IBM Research 
Division 

Earl Swartzlander, University of 
Texas 

Benjamin Wah, University of Illinois 


Monday, MARCH 23 

Workshop on Heterogeneous 
Processing 

Chair: Richard F. Freund, Naval 
Ocean Systems Center 

Session I: Systems 
Session II: Software 
Session III: Applications 

Keynote Address: Heterogeneous 
Network Computing Environments: 
Trends and Issues 

Vaidy Sunderam, Department of 
Mathematics and Computer 
Science, Emory University 

Tutorial 1: Designing Parallel 
Algorithms 

Joseph JaJa’, University of 
Maryland 

Tutorial 2: Using Compositional 
Programming to Write Portable, 
High Performance Parallel 
Programs 

K. Mani Chandy and 

Carl Kesselman, California Institute 

of Technology 


Organizing Committee 
General Chair 

Larry Canter, Computer Systems Approach, Inc. 
Steering Committee Chair 
George Westrom, Odetics, Inc. 


Finances 

Bill Pitts, Toshiba America Information Systems, Inc. 

Publicity 

Sally Jelinek, Electronic Design Associates 

Local Arrangements 

Susamma Barua, California State University, 
Fullerton 


















• March 23-26,1992 

The Beverly Hilton-l 

Sponsored by IEEE Computer Society In cooperation with acm SIGARCH 

Tuesday, MARCH 24 

Wednesday, MARCH 25 

Thursday, MARCH 26 

Keynote Address: On the Role of 

Keynote Address: How to Improve 

Keynote Address: A Look at the 

Randomness in the Design of 
Interconnection Networks 

Parallel System Performance 

David Kuck, University of Illinois at 

Evolution of Software for Numerical 
Linear Algebra 

F. Thomson Leighton, 

Massachusetts Institute of 

Urbana-Champaign 

Jack Dongarra, University of 
Tennessee and Oak Ridge 

Technology 

Commercial Exhibits 

National Laboratory 

Parallel Systems Fair 

(Concurrent Morning) 

Session 10: Algorithms-IV 

Commercial Exhibits 

Commercial Exhibits 

(Concurrent Morning) 

Session 11: Applications-lll 

Session 12: Software-1 

(Concurrent Morning) 

Session 16: Architecture-ll 

Session 17: Applications-V 

Session 1: Algorithms-I 

Session 2: Architectures-1 

(Concurrent Afternoon) 

Session 13: Networks-1 

Session 18: Systems 

Session 3: Mapping/ 

Session 14: Applications-IV 

(Concurrent Afternoon) 

Scheduling-I 

Session 15: Software-II 

Session 19: Networks-ll 

Session 20: Distributed Systems 

(Concurrent Afternoon) 

Session 4: Algorithms-ll 

Session 5: Applications-I 

Panel: HPCC Initiative and the 

Role of Academia 

Session 21: Software-II 

Tutorial 3: Introduction to Parallel 

Session 6: Mapping/ 

Scheduling-ll 

(Concurrent Evening) 

Session 7: Algorithms-lll 

Session 8: Applications-ll 

Session 9: Special Purpose 
Architectures 

Welcome Reception 

Wine & Cheese Reception 

Computing 

Mary Eshaghian, NJIT 

Tutorial 4: Paradigms and Tools 
for Heterogeneous Network 
Computing 

Jack Dongarra, University of 
Tennessee & Vaidy Sunderam, 
Emory University 


For more information, please write the IPPS ‘92 Registrar at the IEEE Computer Society, 1730 
Massachusetts Ave., N.W., Washington, DC 20036-1903 or telephone 202-371-1013 or send 
fax to 202-728-0884. 

The Advance Program may be obtained by anonymous ftp from ftp@usc.edu 
(login as ftp and get pub/ipps92.adpgm). For information on commercial exhibits, send 
message to mary@vienna.niit.edu or fax 714-979-7488. 













A “vanilla” approach 
to modeling, together 
with powerful notions 
of executability and 
code generation, may 
have a profound 
impact on the 
“essence” of developing 
complex systems. 
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Biting the 
Silver Bullet 


Toward a Brighter Future 
for System Development 


David Harel, Weizmann Institute of Science 


I n an eloquent and thoughtful 1986 article, Frederick Brooks expresses his 
I feelings about the illusions and hopes software engineering offers. 1 He argues 
) that many proposed ideas are not “silver bullets” that will deliver us from the 
horrors of developing complex systems. 

Brooks’ article is reminiscent of Parnas’ series of minipapers 2 that accompanied 
his widely publicized resignation from the Strategic Defense Initiative Organiza¬ 
tion (SDIO) Panel on Computing in 1985. Parnas claims that current proposals are 
vastly inadequate to build reliable software as complex as that required for the SDI 
project. 

We thus have two rather discouraging position papers, authored by two of the 
most influential figures in the software world. Neither is a critique of software 
engineering per se, although both make an effort to dissolve myths of magical 
power that people have cultivated concerning certain trends in the field. 

This article was triggered by those of Brooks and Parnas. It is not a rebuttal. 
Indeed, I agree with most of the specific points made in both papers. Instead, the 
goal of this article is to illuminate the brighter side of the coin, emphasizing 
developments in the field that were too recent or immature to have influenced 
Brooks and Parnas when they wrote their manuscripts. 

The two main aspects of these developments have to do with a carefully wrought 
“vanilla” approach to system modeling and the emergence of powerful methods to 
execute and analyze the resulting models. It can be argued that the combined effect 
of these and other ideas is already showing positive signs and appears to have the 
potential to provide a truly major improvement in our present abilities — pro¬ 
foundly affecting the essence of the problem. This might take more than the 10 
years Brooks focuses on. It will surely be a long time before reliable software for 
the likes of the SDI project can be built. Such a system remains an order of 
magnitude too large and too critical to construct today, mainly because of its first¬ 
time-must-work nature. But I also believe that we are on the royal (main) road and 
that the general impression you get from reading the Brooks and Parnas articles is 
far too bleak. 


0018-9162/92/0100-0 
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Past versus present 

Brooks’ arguments. The main prob¬ 
lem, as Brooks rightly sees it, is in spec¬ 
ifying, designing, and testing the “con¬ 
ceptual construct” underlying the system 
being developed, and not in “the labor 
of representing it and testing the fideli¬ 
ty of the representation.” 

“The hard thing about building soft¬ 
ware,” he claims, “is deciding what one 
wants to say, not saying it.” In elaborat¬ 
ing, he mentions the superlinear growth 
in the number of system states, the dif¬ 
ficulty of comprehending the conceptu¬ 
al construct and communicating it to 
others, and what he believes to be its 
inherent unvisualizable character. 

Brooks further argues that, in con¬ 
trast to their apparent appeal, several 
proposed ideas in the field do not con¬ 
stitute magical solutions to the essential 
problems. Among the “nonbullets” he 
discusses are high-level languages, ob¬ 
ject-oriented programming, artificial 
intelligence and expert systems, auto¬ 
matic programming, graphical languag¬ 
es, program verification, and hardware 
improvements. 

In his introduction, Brooks says that 
although he sees no startling break¬ 
throughs in the next decade, “many en¬ 
couraging innovations are under way,” 
and eventually they will be exploited to 
“yield an order-of-magnitude improve¬ 
ment.” 

Brooks mentions two sets of innova¬ 
tions. The first set includes those of the 
above proposals that he doesn’t totally 
discard (for example, high-level languag¬ 
es and object-oriented programming). 
However, he claims that they deal only 
with representation issues, which con¬ 
stitute the accidental part of the prob¬ 
lem. 

The second set of innovations, the 
ones Brooks claims will influence the 
essence, include 

•buying sufficiently general ready¬ 
made software, instead of having it 
tailor-made; 

•refining the requirements itera¬ 
tively and interactively with the cli¬ 
ent, using increasingly better proto¬ 
types; 

• enhancing the design in an iterative, 
top-down fashion, adding lower-lev- 
el details at each step; and 

• finding, hiring, and cultivating ex¬ 
tremely talented designers. 


Despite the encouraging way the 
points are expressed, we come away 
feeling distinctly uncomfortable. Apart 
from ideas that deal with the accidental 
parts of the problem, we are told to buy 
good software from others, hire better 
people than we already have, and con¬ 
tinue with the well-established practic¬ 
es of prototyping and iterative design. 
All the rest is marginal. 

I have discussed Brooks’ article with 
many people over the past few years. 
Most stated that while they agree with 
many of its individual points, the paper 
presents a far gloomier assessment of 
the situation than seems appropriate. I 
feel that this is rooted in some of its 
underlying adopted themes. 

The first is the sharp separation be¬ 
tween the accidental and essential as¬ 
pects of the problem, relegating every¬ 
thing related to representation, 
language, and levels of abstraction to 
the former and only the process of think¬ 
ing about the concepts to the latter. 

The second is the treatment of each 
proposed idea in isolation, with the ac¬ 
companying claim that most of the pro¬ 
posals address representation, so that 
they cannot help with the essence. 

The third involves concentrating on 
only 10 years of the future, which is 
probably too short a period in which to 
expect any significant improvement. 
(About half of this period is already 
behind us.) 

Finally, the discussion is presented as 
a search for a miracle-working silver 
bullet that will slay the werewolf of 
constructing complex software. By ar¬ 
guing that current motifs will not bring 
about that miracle, at least not within 
the next few years, we are left with the 


troubling feeling that the werewolf is 
here to stay. 

We’ve been there before. Since this 
article takes a longer term point of view, 
it is instructive to carry out a brief thought 
experiment. Let’s go back, say 40 years. 
That was the time when instead of grap¬ 
pling with the design of large, complex 
systems, programmers were in the busi¬ 
ness of developing conventional one- 
person programs (which would be on 
the order of 100-200 lines in a modern 
programming language) that were to 
carry out limited algorithmic tasks. Giv¬ 
en the technology and methodology 
available then, such tasks were similar¬ 
ly formidable. Failures, errors, and 
missed deadlines were all around. 

Imagine an article appearing then and 
claiming the essence of the problem to 
be deciding what one wants to say, that 
is, conceiving the algorithm. Writing 
the program is the accidental part. Such 
an article might have asked about the 
availability of a one-stroke solution that 
deals with the essence. From the way 
the issue is presented, it would follow 
that any ideas that relate to representa¬ 
tion and levels of detail can be discount¬ 
ed, because they deal with the nones¬ 
sential parts of the problem. The article 
could very well go on to argue that ideas 
like high-level programming languages, 
compilation, and algorithmic paradigms 
can be safely set aside, since they do not 
deal with the essence. 

However, while none of these ideas 
alone has solved the problem, and while 
it did take more than 10 years for the 
situation to change, we have indeed 
witnessed an order-of-magnitude ad¬ 
vance in our ability to tackle the very 


On biting bullets 

There are two opinions about the origin of the phrase “Biting the bullet.” One 
is that it came from the need to bite the top off the paper cartridge prior to firing 
a certain kind of British rifle used in the mid 19th century. This often had to be 
^ dpns-under^nefnyTrre-afidJEquii^dJ^ping a cool head. 

' The other is that it is an old Americanphrase, roofed in the folklore of the US 
Civil War. It supposedly emerged from the practice of encouraging a patient who 
was to undergo field surgery to bite down hard on a lead bullet to “divert the 
mind from pain and prevent screaming” (R.L. Chapman, American Slang, Harper 
and Row, New York, 1986). 

In more recent years, the phrase has come to signify having to do something 
painful but necessary, or to undertake an activity despite criticism or opposition, 
while exhibiting a measure of courage and optimism. 
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More on the vanilla approach 


It is impossible to provide a detailed account of the vanilla approach to model¬ 
ing in this article. The discussion of it in the text is thus extremely brief. As men¬ 
tioned, the ideas are based on much early work on the specification and design 
of nonreactive systems, suitably extended. 

The three independent efforts that led to this approach are described, respec¬ 
tively, in the Ward and Mellor book, 3 the Hatley and Pirbhai book, 4 and in the 
Harel et al. s publication related to the Statemate system. 

The latter is less informative on the modeling aspects of the approach than 
the two books; its main intention was to describe the supporting tool. However, a 
more detailed description of this modeling framework appears in the following 
manuscript, which should appear in book form in due time: 

Harel, D., and M. Politi, “The Languages of Statemate,” Tech. Report, i-Logix, 

Burlington, Mass., 1991. 

The following paper compares and evaluates these three research efforts (as 
well as a related fourth one). It is quite illuminating and emphasizes the differ¬ 
ences between them, particularly those relevant to modeling behavior: 

Wood, D.P., and W.G. Wood, “Comparative Evaluations of Four Specification 

Methods for Real-Time Systems,” Tech. Report CMU/SEI-89-TR-36, Software 

Eng. Inst., Carnegie Mellon Univ., Pittsburgh, 1989. 

The following book contains interesting discussions and comparisons of these 
and other modeling approaches. It also features a valuable annotated bibliogra¬ 
phy of some 600 items: 

Davis, A. M., Software Requirements: Analysis and Specification, Prentice 

Hall, Englewood Cliffs, N.J., 1990. 


essence of designing one-person pro¬ 
grams. There is absolutely no compari¬ 
son between the process of writing a 
correct and efficient one-person pro¬ 
gram 40 years ago and now. (Actually, 
we need not come all the way to 1992; it 
suffices to compare 1950 with, say, 1975.) 
The grand sum of the many innovations 
that have been suggested and pursued 
in the interim has worked wonders! 

Of course, the situation isn’t perfect. 
There still is a great deal of bad pro¬ 
gramming around, and there are lots of 
incompetent programmers, some terri¬ 
ble programming languages, many mis¬ 
leading methods and guidelines, and 
widespread ignorance of the fundamen¬ 
tals. Nevertheless, most people would 
agree that the werewolves of one-per¬ 
son programs are gone, never to return. 

Vanilla frameworks. Most instrumen¬ 
tal in triggering the revolution in one- 
person programming has been the evo¬ 
lution of a fitting, general-purpose 
conceptual framework, which we shall 
call “vanilla.” Its main contribution was 


to free the programmer from having to 
think on an inappropriate level of de¬ 
tail, enabling him or her to conceive of 
an idea for solving an algorithmic prob¬ 
lem and to map it easily from the mind 
into an appropriate high-level medium. 

The cornerstone of this framework is 
a collection of fundamental notions and 
concepts that includes the basic dichot¬ 
omy between data and control and con¬ 
venient means for structuring and com¬ 
bining them into an algorithmic whole. 
Thus, elementary control structures, data 
types, and data structures were identi¬ 
fied, and we learned how to wield them. 
A rich variety of algorithmic methods 
was devised, including divide and con¬ 
quer, dynamic programming, and greedy 
paradigms; these were adapted to fit a 
variety of problem sets. Notions of cor¬ 
rectness and efficiency were introduced, 
together with methods for establishing 
the former and estimating the latter. 

In parallel, and based on these con¬ 
cepts, a corresponding set of vanilla high- 
level programming languages evolved, 
supported by powerful and sophisticat¬ 


ed tools for testing and analyzing. We 
learned to rely on the theory of compu¬ 
tational complexity to help us find effi¬ 
cient algorithms or to detect our stum¬ 
bling upon an intractable problem; we 
have begun to understand the great vir¬ 
tues of parallelism, approximation, and 
randomization in obtaining even better 
solutions. 

Thus, for one-person programs, acci¬ 
dental and essential issues were inti¬ 
mately and unavoidably intertwined. 

Of course, as time went by, other 
flavors, more exotic than vanilla, natu¬ 
rally emerged, such as applicative, func¬ 
tional, and logic programming styles, as 
well as more esoteric approaches like 
systolic arrays and neural nets. For each, 
the basic notions and concepts have had 
to be redefined, and new languages and 
tools have been developed. The arsenal 
has thus grown considerably and has 
become richer and more varied — a 
sure sign of healthy evolution. 

Back to the future. I believe the cur¬ 
rent situation is similar, except that we 
are now in the business of developing 
very complex systems. These systems 
are to consist of large amounts of soft¬ 
ware and hardware and are often of a 
distributed nature. Their size and com¬ 
plexity, as Brooks and Parnas observe, 
is formidable when compared to one- 
person programs. By their very nature, 
they also involve large numbers of tech¬ 
nical personnel. 

The rest of this article is restricted to 
a class of systems that has been termed 
reactive. 56 This class includes many kinds 
of embedded, concurrent, and real-time 
systems, but excludes data-intensive 
ones such as databases and manage¬ 
ment information systems. Reactive sys¬ 
tems are widely considered to be partic¬ 
ularly problematic, posing some of the 
greatest challenges in this field. 

Building on a solid foundation of time- 
honored work in software and systems 
engineering, a number of developments 
have taken place in the past several 
years. Although not yet universally ac¬ 
cepted as such, I submit that they com¬ 
bine to form the kernel of a solid gener¬ 
al-purpose vanilla approach (see the 
sidebar) to the development of complex 
reactive systems. Moreover, encourag¬ 
ing research is under way in a number of 
related fields that has fundamental im¬ 
plications regarding these ideas. 

The climate suggests that we stand to 
witness a grand-scale improvement in 
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the process of constructing such 
systems. It is hard to predict a 
time frame for this, but the scope 
of the benefits it will bring about 
could very well match the strik¬ 
ing changes we have witnessed in 
solving one-person algorithmic 
problems. 

We now discuss the two com¬ 
ponents of these developments: 
means for modeling the system, 
and techniques for inspecting and 
analyzing the model. 

Modeling the 
system 

To model systems, we need an 
underlying set of fundamental 
concepts and notions—some call 
them “abstractions” — that, in 
Brooks’ terminology, capture the 
“conceptual construct” of com¬ 
plex systems. Deciding what they 
are and how they relate is analo¬ 
gous to the separation of data 
and control in the vanilla approach 
to one-person programs and the identi¬ 
fication of appropriate ways of structur¬ 
ing, expressing, and combining them. 
For a nonexotic first cut at the problem, 
these concepts must be sufficiently gen¬ 
eral to be widely applicable, even at the 
expense of being somewhat mediocre. 
To be amenable to inspection and anal¬ 
ysis, they must also be rigorous and 
precise, with underlying formal seman¬ 
tics. 

The vanilla approach is rooted in the 
early work of Parnas and others on 
modularization and information hiding, 7 
and in that of several researchers on 
structured analysis and structured de¬ 
sign 8 ' 9 that dealt mainly with data-inten- 
sive systems. The backbone of the sys¬ 
tem model should be a hierarchy of 
activities, as we’ll call them, that capture 
the functional capabilities of the system 
— suitably decomposed to a level with 
which the designer is happy. (The activ¬ 
ities need not be arranged in strict hier¬ 
archies. The breakup, or decomposi¬ 
tion, may have overlappings, with 
elements on any level being shared by 
multiple parent elements. The term “hi¬ 
erarchy” used here thus carries a more 
flexible connotation.) 

Data elements and data stores are 
also specified therein, and are associat¬ 
ed as inputs and outputs that flow be¬ 



tween the activities on the various lev¬ 
els. The semantics of this kind of func¬ 
tional description is dynamically non¬ 
committing in that it merely asserts that 
activities can be active, information can 
flow, and so on. It does not contain 
information about what will happen, 
when it will happen, or why it will hap¬ 
pen. As a consequence, this hierarchy 
can only serve as part of a conceptual 
model for truly reactive systems — such 
as control and communication systems 
or embedded real-time systems, which 
have a crucial behavioral side that has 
to be addressed, too. 

Some time ago, a number of indepen¬ 
dent research groups extended these 
widely accepted ideas to deal with reac¬ 
tive systems. 3 ' 5 Their efforts resulted in 
a surprisingly similar set of conclusions. 
Using their own terminology and em¬ 
phasis, they each recommended that the 
hierarchy of activities be enriched with 
behavioral descriptions we’ll call con¬ 
trol activities, which potentially appear 
on all levels. 

Control activities serve as the central 
nervous system, so to speak, of the mod¬ 
el. They are meant to sense and control 
the dynamics of that portion of the func¬ 
tional description on their level. This 
includes the ability to activate and de¬ 
activate activities, cause data to be read 


and written, and sense when such 
things have happened — thus 
affecting subsequent behavior. 
The resulting combination is the 
system’s conceptual model. 

The recommendations also call 
for a structural, or architectural, 
description of the system to deal 
with such notions as subsystems 
and modules, channels and phys¬ 
ical links, and storage compo¬ 
nents. This description can thus 
be considered the system’s phys¬ 
ical model. The conceptual and 
physical models are related by a 
mapping that assigns implemen- 
tational responsibility for the var¬ 
ious parts of the former to those 
of the latter. 

Modeling behavior. While the 
functional description is the back¬ 
bone of the conceptual model, 
the behavioral descriptions (that 
is, the control activities) are, in a 
crucial sense, its heart and soul. 
Behavior over time is much less 
tangible than either functional¬ 
ity or physical structure, and 
more than anything else, this is the as¬ 
pect that renders reactive systems so 
slippery and error-prone. 

In the realm of dynamic behavior, 
there is a particularly dire need for ap¬ 
proaches that are sufficiently clear and 
well-structured to enable designers to 
capture their thinking in a coherent and 
comprehensive fashion. Moreover, be¬ 
havioral descriptions must possess rig¬ 
orous underlying semantics; all too of¬ 
ten, insufficient attention has been paid 
to semantics. The discussion of analysis 
below will show how important this is. 

The aforementioned research groups 3 ' 5 
more or less agree that behavioral con¬ 
trollers should be described using modes, 
or states, together with control elements, 
such as events and conditions, that trig¬ 
ger transitions between them. Implicit¬ 
ly, they have also adopted a subtle ab¬ 
straction, termed the synchrony 
hypothesis, 10 according to which every¬ 
thing takes zero time unless explicitly 
prescribed otherwise. However, there 
is no agreement as to exactly how this is 
to be turned into a workable medium 
for modeling reactive behavior. It is 
clear that conventional finite-state ma¬ 
chines will not do, due to their lack of 
structure, their verbosity, and the noto¬ 
rious state-explosion phenomenon. 

The basic elements of reactive behav- 
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ior (states, transitions, events, condi¬ 
tions, and time) must be allowed to be 
properly and naturally conceptualized, 
structured, and combined so that fun¬ 
damental patterns of reactive behavior 
— like sequentiality, concurrency, and 
synchronization — will mesh smoothly 
with the functional decomposition. 

A number of solutions have been sug¬ 
gested by these groups. They range from 
variants of communicating finite-state 
machines, 3 - 4 through combinational de¬ 
cision tables and other similar means, 4 
to a relative newcomer—statecharts. 511 
Other formalisms, such as Petri nets, 
temporal logic, 6 or certain languages 
especially tailored for real-time sys¬ 
tems, 10 would be reasonable choices, 
too. 

Modeling data. Although data-inten- 
sive systems are not the subject of this 
article, a few words regarding the issue 
of incorporating data modeling into the 
vanilla framework are in order. 

Conventional data elements and data 
structures can be specified and manipu¬ 
lated in standard ways within behavior¬ 
al descriptions or in bottom-level activ¬ 
ities. To deal with large-scale pools of 
data, such as databases or knowledge¬ 
bases, we would have to use a separate 
data-modeling medium, such as a suit¬ 
ably adapted version of Chen’s entity- 
relationship approach. 3 - 412 The result¬ 
ing descriptions would then be associated 
with the data stores. 

Incorporating data-modeling tech¬ 
niques into the present framework could 
serve as an excellent melting pot for 
combining ideas from the world of data- 
intensive systems with ones from the 
world of reactive systems. 

Strata of conceptual models. Brooks 
states that descriptions of software that 
abstract away its complexity often also 
abstract away its essence — the com¬ 
plexity itself being part of the essence. 
Obviously, he is right. Indeed, it is im¬ 
portant to use the vanilla approach in a 
way that does not hide the system’s 
essential complexity. Proper use actual¬ 
ly enables harnessing and taming that 
complexity by allowing the designer to 
capture the system’s inherent concep¬ 
tual structure in a natural way. 

Regardless of how well devised it 
might be, one conceptual model might 
not be enough to take us from our initial 
thoughts to a final working implemen¬ 
tation. While it is possible to construct a 
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good functional hierarchy, interweaved 
with its controlling activities, the map¬ 
ping we specify between that model and 
the physical model often turns out to be 
naive, rarely constituting a satisfactory 
full-fledged implementation. Conse¬ 
quently, we must often add a new di¬ 
mension to the modeling process by re¬ 
peatedly refining the conceptual model. 

This can be done by preparing a new 
tier, or stratum, of functional hierar¬ 
chies, one for each of the subsystems 
appearing in the structural view, and 
providing a lower-level mapping between 
these refined models and the subsystems 
themselves. This process may continue 
downward until a satisfactory level of 
design is reached. 

These ideas are quite in line with 
Brooks’ sympathetic discussion of top- 
down design. Of course, two crucial parts 
of this process concern the methodolog¬ 
ical issue of providing guidelines and 
heuristics for actually carrying it out, 
and the technical issue of showing con¬ 
sistency between the resulting strata. 
These are briefly discussed below. 

Visual representation. Most issues of 
representation have been skirted above; 
indeed, some justification could be found 
in giving them second-class status. How¬ 
ever, I believe that convenient media 
for representing the concepts and struc¬ 
tures inherent in a model impact the 
very thinking that goes into construct¬ 
ing that model. In the one-person pro¬ 
gramming world, the availability of pro¬ 
gramming languages such as Pascal and 
C and even their precursors like For¬ 
tran, Algol, and PL/I has had a profound 
influence on a programmer’s ability to 
conceive of good algorithms. Moreover, 
good representation is also instrumen¬ 
tal in communicating those algorithms 
and their underlying ideas to others. 

I agree with Brooks that flowcharts 


have become pitiful visualizations of 
programs, and even with a more general 
claim concerning the hopelessness of 
finding a general-purpose visual pro¬ 
gramming language that could replace 
conventional languages. But this opin¬ 
ion comes to a screeching halt where 
complex reactive systems are con¬ 
cerned. 

Much of the conceptual construct 
underlying a complex reactive system is 
inherently topological in nature, and 
this is reflected in the vanilla approach 
outlined above. Hierarchies, with or 
without overlapping, and multilevel re¬ 
lationships, whether they concern struc¬ 
ture, function, or behavior, can be cap¬ 
tured naturally by simple, rigorous, and 
well-known notions from set theory and 
topology; these, in turn, have natural 
counterparts as spatial/graphical repre¬ 
sentations. 

As argued elsewhere, 12 this fact gives 
rise to visual formalisms, in which en¬ 
capsulation, connectedness, and adja¬ 
cency play central roles, and lesser fea¬ 
tures, such as size, shape, and color, can 
also be exploited. Furthermore, all these 
graphical features come complete with 
rigorous mathematical semantics. 

Visual formalisms have indeed been 
proposed for representing the various 
aspects of vanilla models. 3 51112 From 
several years of following their applica¬ 
tion in large real-world projects, I have 
become convinced that using appropri¬ 
ate visual formalisms can have a spec¬ 
tacular effect on engineers and program¬ 
mers. (An example of this is the avionics 
system for the state-of-the-art Lavi fight¬ 
er at Israel Aircraft Industries, where 
the visual language of statecharts 11 was 
used for specification. Although these 
experiences are too recent to have yield¬ 
ed statistics, some comparisons and eval¬ 
uations have already appeared.) 

Moreover, this effect is not limited to 
mere accidental issues; the quality and 
expedition of their very thinking was 
found to be improved. Successful sys¬ 
tem development in the future will re¬ 
volve around visual representations. We 
will first conceptualize, using the “prop¬ 
er” entities and relationships, and then 
formulate and reformulate our concep¬ 
tions as a series of increasingly more 
comprehensive models represented in 
an appropriate combination of visual 
languages. A combination it must be, 
since system models have several fac¬ 
ets, each of which conjures up different 
kinds of mental images. 
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Of course, the job is far from com¬ 
plete. Some aspects of the modeling 
process have not been as forthcoming 
as others in lending themselves to good 
visualization. Algorithmic operations on 
variables and data structures, for exam¬ 
ple, will probably remain textual. In 
addition, as Brooks aptly observes, some 
of the less obvious connections between 
the various parts of system models are 
not easily visualized. However, for a 
number of years, we have been doing 
far, far better than the “several, general 
directed graphs, superimposed one upon 
another” Brooks’ describes. The graph¬ 
ical languages currently used are still 
two-dimensional, whereas some of the 
concepts could definitely do with high¬ 
er dimensional visualization. This may 
still happen. In fact, realistic motion- 
based 3D techniques are rapidly com¬ 
ing into reach. A new aspect of visual 
languages that will have to be addressed 
is computerized support for the “nice 
looking” layout of diagrams. This is a 
difficult and challenging protyem in 
which only marginal progress has been 
made. 

Regarding hardware, our scopes are 
currently of limited scope, to use Brooks’ 
captivating phrase, making the extent 
to which we can comfortably display 
very large visual models dependent on 
the availability of dramatically improved 
graphical hardware. Rather than taking 
this as a reason to abandon visual ap¬ 
proaches, we should find it enlighten¬ 
ing. For once, concepts and software 
ideas are ahead, waiting for the devel¬ 
opment of matching hardware. If the 
past record of hardware improvements 
is any measure, these developments will 
not be long in coming. 

It is our duty to forge ahead to turn 
system modeling into a predominantly 
visual and graphical process. I believe 
this is one of the most promising trends 
in our field. 

Methods and guidelines. In addition 
to thinking with the “right” concepts 
and representing the resulting thoughts 
in appropriate programming languag¬ 
es, a programmer can call on a variety of 
well-established methods, guidelines, 
and techniques to help formulate a good 
solution to a one-person algorithmic 
problem. These constitute a large reser¬ 
voir of knowledge accumulated over 
years, embodying the experience and 
expertise of generations of program¬ 
mers, algorithm designers, and comput- 
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er scientists. As might be expected, there 
has always been a great deal of cross¬ 
fertilization between the world of meth¬ 
ods and techniques and the world of 
concepts and languages. 

The story for complex reactive sys¬ 
tems is no different, except that it is at a 
far more embryonic stage. Despite the 
proliferation of so-called methodolo¬ 
gies, it is still too early to see a wide- 
ranging and well-understood collection 
of guidelines and techniques for the 
step-by-step process of system develop¬ 
ment. 

Many of the proposed methodologies 
are not methodologies at all in that they 
do not contain recommendations about 
how to actually do things. For that mat¬ 
ter, the vanilla approach described here 
is not a methodology either. However, 
what is worse is that many do prescribe 
recipes, but these often suffer from be¬ 
ing too restrictive, hard to apply, or 
downright wrong. 

One of the most unfortunate trends 
has been in presenting a method as ex¬ 
clusive, that is, preaching about its be¬ 
ing the step-by-step way to develop en¬ 
tire systems. This can be compared in 
naivete to someone advocating divide- 
and-conquer or branch-and-bound as 
the method to write programs. 

The availability of a solid, general- 
purpose framework within which one 
can conceptualize, capture, and repre¬ 
sent a system model seems to be far 
more important right now. All-encom¬ 
passing recipes for how to get the work 
done simply do not exist; guidelines and 
techniques that work in special cases do 
exist, and more will surface in time. 
Obviously, they will be influenced by 
the choice of the framework and will, in 
turn, influence that framework and its 
evolution. And they will draw heavily 
on our experience in wielding the no¬ 
tions, concepts, languages, and tools. 


Among the guidelines suggested are 
top-down and bottom-up approaches, 
which prescribe the raw order of things, 
as well as approaches related to the 
nature of the elements that are to drive 
the process, such as state-driven, func¬ 
tion-driven, or data-driven techniques. 

In principle, all of these can be fol¬ 
lowed quite smoothly within the vanilla 
framework, though constructing really 
good models, as well as choosing which 
of these guidelines to use for what sys¬ 
tems, will obviously remain something 
of an art. 

Some methods are further removed 
from the vanilla framework, since they 
advocate a somewhat different set of 
basic concepts. One of the better-known 
examples is the object-oriented ap¬ 
proach, in which objects and their capa¬ 
bilities take precedence over activities 
and states. While it is possible to follow 
this approach within the confines of our 
basic framework, it’s perhaps not as 
smooth-going as one would like. This is 
an excellent example of a more special¬ 
ized, or exotic, flavor, which is already 
resulting in correspondingly specialized 
advances in languages and tools. 

In addition to guidelines for the over¬ 
all process of development, a number of 
heuristics have been addressed at the 
nontrivial process of mapping the con¬ 
ceptual model onto the physical one. 
They are often based on taking subtle 
advantage of the cohesion and coupling 
of activities. 4 - 7 

For pure software systems, this task is 
usually less perplexing, since the struc¬ 
ture of the final product can be taken to 
correspond reasonably well with that of 
the conceptual model. However, em¬ 
bedded systems are different. In them, 
the physical breakup into components 
and subcomponents might be acutely 
orthogonal to the conceptual structure. 
These cases require more iterations in 
the design process, giving rise to several 
strata of physical and conceptual mod¬ 
els, as discussed above. The importance 
of such heuristics stems from such cas¬ 
es. (These heuristics could well find their 
way into useful expert-system support 
tools, as envisioned by Brooks.) 

Designers would do well to master all 
of these techniques, guidelines, and heu¬ 
ristics, and to use them to devise models 
in a manner that they deem most natu¬ 
ral. In time, I’m certain we will outgrow 
the deep convictions we have cultivated 
around the various methodologies. We 
will stop trying to get everyone to use 
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Tools for model execution 


Although model execution is not a new idea, its vast potential has not yet been 
fully exploited. All the executability features discussed in the text are available in 
the Statemate tool, 5 the first release of which was developed between 1984 and 
1987. It is currently being used mainly in the areas of avionics, telecommunica¬ 
tion, and process control. 

A number of additional tools support some of these features. A couple of them 
are commercially available, and others are still in research and development stag¬ 
es. Here are a few additional publications describing techniques and tools for ex¬ 
ecuting models: 

Diaz-Gonzalez, J., and J. Urban, “Prototyping Conceptual Models of Real-Time 
Systems: A Visual Perspective," Proc. 22nd Hawaii Int’l Coni. System Sciences, 
IEEE CS Press, Los Alamitos, Calif., Order No. 1912, 1989, pp. 358-367. 

Jensen, K., “Computer Tools for Construction, Modification, and Analysis of 
Petri Nets," Advances in Petri Nets, Part II, W. Brauer, W. Reisig, and G. Ro- 
zenberg, eds., Lecture Notes in Computer Science, Vol. 255, Springer-Verlag, 
New York, 1987, pp. 4-19. 

Pulli, P. J., “Pattern-Directed Real-Time Execution of SA/RT Specifications,” 
Proc. Euromicro Workshop on Real-Time, IEEE CS Press, Los Alamitos, Calif., 
Order No. 1956, 1989, pp. 3-9. 

Wang, Y„ “A Distributed Specification Model and its Prototyping,” IEEE Trans. 
Software Eng., Vol. 14, No. 8, Aug. 1988, pp. 1,090-1,097. 

Zave, P., and W. Schell, “Salient Features of an Executable Specification Lan¬ 
guage and Its Environment," IEEE Trans. Software Eng., Vol. 12, No.2, Feb. 
1986, pp. 312-325. 


them exclusively for all systems, and 
they will reduce to their proper dimen¬ 
sions — taking their place side by side in 
our bag of tricks, just as conventional 
algorithmic methods have for one-per¬ 
son programs. 

Analyzing the model 

The preceding sections have repeat¬ 
edly invoked the analogy between con¬ 
ventional algorithms and models of com¬ 
plex systems. When it comes to semantics 
and analysis, this analogy takes on a 
particularly interesting twist. 

Although the importance of testing 
and analyzing one-person algorithms has 
always been acknowledged, the world 
of complex systems has long suffered 
from something of an indifference to 
such needs. By analogy, the situation 
was as if we were asked to solve one- 
person algorithmic problems without 
the possibility of running programs, and 
hence without being able to test and 
debug them at all. 


Indeed, many past approaches to sys¬ 
tem development provided no means 
for capturing behavior, being centered 
instead on the functional aspects and 
dataflow. The approaches that did pro¬ 
vide such means were informal, lacking 
the rigorous semantics necessary for even 
beginning to analyze the dynamics. 
Hence, it was impossible to predict in 
early stages how the system would be¬ 
have if constructed according to the 
model. 

Not until actual code was written — 
usually at a very late stage in the project 
by people other than those responsible 
for and capable of developing the “con¬ 
ceptual construct” and at much greater 
expense — could one expect to get reli¬ 
able answers to “what if?” questions. 
This, of course, has had a deplorable 
effect on the expedition and quality of 
development efforts for large and com¬ 
plex systems. 

As a consequence, most computer¬ 
ized tools that flourished around such 
methods (computer-aided software en¬ 
gineering — CASE — tools, as they are 


often called) concentrated on provid¬ 
ing mere graphic-editing capabilities, 
sometimes accompanied by document 
generation, version control, and project 
management facilities. Their propo¬ 
nents heralded the ability of these tools 
to check model “consistency and com¬ 
pleteness,” which is really just a grand 
form of syntax checking. 

To use my analogy again, it is like 
making sure, in a conventional pro¬ 
gram, that the begins and ends match, 
that procedure calls have the right num¬ 
ber and types of parameters, and that 
all declared variables are indeed used. 
In the complex system arena, such 
checking includes the consistency of 
level-labeling schemes and of inputs 
and outputs within the hierarchies, the 
nonredundancy of flow elements, and 
so on; it is analogous to the checking 
carried out in one-person programming 
environments on-the-fly or in simple 
precompilation stages. 

Since designing a complex reactive 
system is so much more massive and 
intricate an undertaking than writing a 
conventional one-person program, test¬ 
ing for consistency and completeness 
in system modeling is far more impor¬ 
tant than syntax checking in programs. 
Nevertheless, it remains a mere test of 
the syntactic integrity of the model and 
has very little to do with that model’s 
conceptual and logical aspects. 

Checking that a model is consistent 
and complete cannot prevent logical 
errors that cause a missile to fire un¬ 
intentionally or a stock market system 
to run amok — exactly the kinds of 
mishaps that are at the heart of our 
problem. For this, we need the ability 
to carry out real testing and analysis. 

You may feel the following discus¬ 
sion is unrealistically futuristic. Not so. 
All the possibilities we mention have 
been implemented in a computerized 
tool that supports the vanilla approach 
and that is being used in the develop¬ 
ment of real systems. 4 Several other 
tools also support some of these possi¬ 
bilities (see the “Tools for model exe¬ 
cution” sidebar). 

None of the implementations is per¬ 
fect; each requires improvements and 
extensions. However, they do corrobo¬ 
rate the feasibility of the ideas sum¬ 
marized below. In fact, since many of 
these ideas are standard practice in 
the world of conventional programming, 
the tools appear to be the first complex- 
system analogs of useful general-pur- 
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pose programming en¬ 
vironments. 

Model execution. 

One of the most inter¬ 
esting notions to come 
out of recent work in 
systems engineering is 
that of executable spec¬ 
ifications or, to fit in 
better with the termi¬ 
nology used here, exe¬ 
cutable models. Exe¬ 
cuting a model 
analogous to running 
a program directly, 
with the aid of an in¬ 
terpreter. Unfortu¬ 
nately, the term has 
been erroneously 
equated with the ani¬ 
mation of diagrams 
only. However, execut- 
ability is in fact many-sided and far more 
significant. 

A prerequisite to executing complex 
system models is the availability of a 
formal semantics for those models — 
most notably, for the medium that cap¬ 
tures the behavioral view. Thus, while 
the adjective “visual” in the term “visu¬ 
al formalism” 12 was justified earlier on 
grounds pertaining to model represen¬ 
tation, the word “formalism” is justified 
now on grounds pertaining to model 
analysis. 

The core of model execution is the 
ability to carry out a single step of the 
system’s dynamic operation, with all 
consequences taken into account. Dur¬ 
ing a step, the environment can gener¬ 
ate external events, change the truth 
values of conditions, and update vari¬ 
ables and other data elements. Such 
changes then affect the status of the 
system; they trigger state changes in the 
controllers, activate and deactivate ac¬ 
tivities, modify conditions and variables, 
and so on. In turn, each of these changes 
can cause many others, often yielding 
intricate chain reactions. 

A semantics for the model must con¬ 
tain sufficient information to capture 
these ramifications precisely. Given the 
current status and the changes made by 
the environment, calculating the effect 
of a step usually involves complicated 
algorithmic procedures, which are de¬ 
rived from, and reflect, that semantics. 

Interactive and batch execution. The 

simplest way to execute, or “run,” the 


model using a computerized tool is in a 
step-by-step interactive fashion. At each 
step, the user emulates the system’s 
environment by generating events and 
changing values. The tool, in turn, re¬ 
sponds by transforming the system into 
the new resulting status. If the model is 
represented visually, the change in sta¬ 
tus will also be reflected visually, say, by 
changes in color or emphasis in the dia¬ 
grams. 

Once we have the basic ability to 
execute a step, our appetite grows. We 
might now want to see the model exe¬ 
cuting noninteractively. To check, for 
example, that a telephone call connects 
when it should, we can prepare the rel¬ 
evant sequence of events and signals in 
a batch file, set up the model to start in 
the initial status, and ask our tool to 
execute steps iteratively, reading in the 
changes from the file. The graphic feed¬ 
back from such a batch execution be¬ 
comes an (often quite appealing) ani¬ 
mation of the diagrams. 

By executing scenarios that reflect 
the way we expect our system to be¬ 
have, we are able to verify that it will 
indeed do so — long before final imple¬ 
mentation. If we find that the system’s 
response is not as expected, we may go 
back to the model, change it, and run 
the same scenario again. This is analo¬ 
gous to single-step — or batch — de¬ 
bugging of conventional programs. 

It should be emphasized that scenar¬ 
ios can be run at any time in the devel¬ 
opment effort, as long as the portion of 
interest is syntactically legal. During an 


execution, the user 
plays the role of all parts 
of the model that are 
external to the portion 
being executed, even if 
those parts will eventu¬ 
ally be specified and 
thus become internal. 

Again, from several 
years of seeing such ex¬ 
ecution capabilities 
used, mainly in large 
aerospace and electron¬ 
ic industries, I have be¬ 
come convinced of their 
value (again, no statis¬ 
tics are yet available to 
quantify this impres¬ 
sion, although a couple 
of preliminary case 
studies have appeared). 
These execution capa¬ 
bilities appear to intro¬ 
duce an entirely new and powerful di¬ 
mension into the task of verifying and 
debugging system models. 

I have seen model executions uncov¬ 
ering hitherto unknown patterns of be¬ 
havior, when the members of the devel¬ 
opment team thought they had covered 
everything. As a result, these people 
were able to discuss deep behavioral 
issues that would otherwise have been 
swept under a rug of enormous unread¬ 
able specification documents. 

I have seen engineers use executabil- 
ity to tackle crucial problems and, very 
early in the project, correct subtle con¬ 
ceptual errors — ones that could other¬ 
wise go undiscussed or undetected until 
it was too late. And typically, all these 
phenomena start to take place as soon 
as the first executions are run. 

Customer representatives are often 
involved in these stages, which further 
supports what Brooks and others have 
urged: extensive prototyping and simu¬ 
lation of the system early on with the 
client. 

Programmed execution. Our appe¬ 
tite now becomes even greater. We now 
might ask ourselves: If the tool can ex¬ 
ecute the model in detail, reading events 
in from a file, why should we be satisfied 
with merely witnessing the run in action 
and inspecting the final status? We would 
like to be able to incorporate break¬ 
points, causing the execution to sus¬ 
pend and the tool to take certain actions 
when particular situations come up. 
These actions can range from tempo- 
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rarily entering interactive mode (in 
order to monitor careful step-by-step 
progress) to executing a piece of ready¬ 
made code that describes a bottom- 
level activity. 

In fact, we need not restrict our¬ 
selves to running self-devised scenari¬ 
os. We might want to see the model 
executing under circumstances that we 
do not care to specify in detail. We 
might like to see its performance un¬ 
der random conditions and in both 
typical and less-than-typical situations. 
Such a capability gets to the heart of 
the need for an executable model: to 
minimize the unpredictable in the de¬ 
velopment of complex systems. 

This more powerful notion of in¬ 
specting a model is achieved by the 
idea of programming executions, using 
a special metalanguage supported by 
the tool. Programs in this language 
(which might be appropriately termed 
an execution control language) can be 
set up to look out for predefined break¬ 
points and accumulate information 
regarding the system’s progress as it 
takes place. 

As a simple example, in a typical 
flight of an aircraft we are specifying, 
we might want to know how many 
times the radar loses a locked-on tar¬ 
get. Since it might be difficult for the 
engineer to put together a typical flight 
scenario, we can tap the power of our 
tool by instructing it to run many typ¬ 
ical scenarios, using the accumulated 
results to calculate average-case infor¬ 
mation. 

The tool follows typical scenarios by 
generating random numbers to select 
new events according to predefined 
probability distributions. The statis¬ 
tics are then gathered using appropri¬ 
ate breakpoints and simple arithmeti¬ 
cal operations. The ideas behind these 
techniques are, of course, well known. 
However, the point is to extend them 
to conceptual models of complex sys¬ 
tems, long before the costly final-im¬ 
plementation stages. 

In a similar vein, we can use pro¬ 
grammed executions to apply other, 
more powerful kinds of dynamic tests 
to system models. For example, we 
might set up an execution control pro¬ 
gram to carry out performance analy¬ 
sis. If we want to check whether an 
operating system we are modeling will 
ever require more main memory than 
some maximum allowed value, we can 
associate with the relevant activities in 


We can use 

programmed executions 
to apply other, more 
powerful kinds of 
dynamic tests to system 
models. 


the functional view values that repre¬ 
sent our knowledge about their memo¬ 
ry consumption. We can then program 
the tool to run many typical scenarios, 
calculating the maximum memory con¬ 
sumption of all activities that are active 
simultaneously. 

Despite its being applied to a system 
model, and not to a final implementa¬ 
tion, this approach to analysis is far 
more informative than the extraction of 
worst-case estimates from simple graphs 
of process dependencies. The model 
being analyzed will (hopefully) be real¬ 
istic and detailed, and executing it re¬ 
flects precisely what would have hap¬ 
pened had we run the real system instead. 

If our analysis shows that the memory 
limit might indeed be exceeded, the tool 
can support that prediction by supply¬ 
ing the actual sequence of events that 
would cause it. Clearly, by replacing 
memory values with time information, 
similarly meaningful timing analysis can 
be carried out as well. 

In general, then, carefully pro¬ 
grammed executions can be used to in¬ 
spect and debug the system model un¬ 
der a wide range of test data to emulate 
both the environment and the as-yet- 
unspecified parts of the system and to 
analyze the model for performance and 
efficiency. 

Exhaustive executions. When execut¬ 
ing the model, we might detect such 
unpleasant anomalies as deadlocks or 
behavioral ambiguities (nondetermin¬ 
ism). However, finding and eliminating 
these in the cases that we happen to 
encounter does not ensure they will 
never occur in the lifetime of the sys¬ 
tem. It would be extremely useful to be 
able to run through all possible scenar¬ 
ios in search of such situations, by gen¬ 
erating all possible external events and 


all changes in the values of conditions 
and variables. 

We might also be interested in reach¬ 
ability tests, which would determine 
whether — when started in some given 
initial situation — the system can ever 
reach a situation in which some speci¬ 
fied condition becomes true. This con¬ 
dition can be made to reflect desired or 
undesired situations. Moreover, we 
could imagine the test’s being set up to 
report on the first scenario it finds that 
leads to the specified condition, or to 
report on all possible ones, producing 
the details of the scenarios themselves. 
We thus arrive at the idea of exhaustive 
executions. 

Are such tests realistic? Could we 
subject the model to an exhaustive 
reachability test, for example, after 
which we will know for sure whether 
there is any possibility of its occurring 
under any possible circumstances? The 
answer, in principle, is yes, but with 
serious reservations. The number of 
possibilities that might have to be con¬ 
sidered in an exhaustive execution can 
easily become incredibly large, even if 
we ensure that it is finite by limiting the 
possible values of the variables. 

To get a feel for the sizes involved, a 
behavioral model that contains about 
40 concurrent components, each with 
about 10 states, has more state config¬ 
urations and, hence, might have more 
possible scenarios than the number of 
elementary particles in the entire uni¬ 
verse. There can never be a language, 
method, or tool with which one can, in 
general, consider all of these in any 
reasonable amount of time. 

This doesn ’t mean, however, that such 
tests are a bad idea( 

First, the above numbers denote 
worst-case asymptotic estimates; a real 
system might very well have far fewer 
scenarios that can actually happen, and 
a careful process of considering only 
those that are feasible will take far less 
time than the worst-case estimate. 

In fact, just such a reachability test 
was recently applied to a model of the 
firing mechanism of a certain, already 
deployed, ballistic missile system (The 
Statemate system 5 was used fo. >his. 
The main part of the underlying model 
consisted of a statechart 11 with about 
80 states. However, since these includ¬ 
ed parallel state components, the real 
number of states was much larger.) In 
less than three hours on a standard 
workstation, the test terminated, in the 
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process discovering a new sequence of 
events, unknown to the design team, 
that leads to the firing of the missile! 

Second, exhaustive tests can be run 
on small, critical, and well-isolated parts 
of the model. We can instruct the tool to 
ignore some of the external events or to 
avoid simulating the details of certain 
activities. Clearly, this can cause it to 
overlook crucial situations, but the ad¬ 
vantage is that the set of scenarios it 
considers is greatly reduced. To maxi¬ 
mize the test’s effectiveness, such limit¬ 
ing constraints should be prepared very 
carefully, using as much knowledge of 
the modeled system as possible. This is 
another place where expert systems 
might come in handy. 

Third, even if exhaustive tests cannot 
always be completed in reasonable 
amounts of time, it would be wise to 
have them run in the background, per¬ 
haps at night or on weekends, for as 
long as we can afford. There is nothing 
wrong with routinely submitting large 
system models to powerful supercom¬ 
puters for exhaustive testing, even non- 
exhaustively. Since the tool can be set 
up to report on phenomena as they are 
discovered, the more time we observe 
such tests running without surprises the 
more confidence we have in the integri¬ 
ty of our model. 

Watchdogs and temporal verification. 

Often, we are interested in establishing 
properties of the model that are of a 
global nature but are more involved 
than reachability or freedom from dead¬ 
lock. Suppose we want to make sure 
that a certain party in a communication 
protocol never sends two consecutive 
messages unless a special item, say, an 
acknowledgment, is sent in the interim. 

Although seemingly more complicat¬ 
ed, this query can be cast in the form of 
a reachability test in the following way. 
First, construct a small special-purpose 
“piece” of behavioral specification that 
is carefully set up to enter a special state 
if and when the offending situation oc¬ 
curs. Next, attach this watchdog, as it is 
called, to the original model as a con¬ 
current behavioral component and run 
a reachability test on the extended model 
to find out whether the special state can 
ever be entered. Since the watchdog 
runs in parallel with the rest of the mod¬ 
el, the effect will be as desired. 

Watchdogs can be used to verify the 
model against a wide variety of proper¬ 
ties. Temporal logic, 6 one of the most 



useful and well-known media for speci¬ 
fying global constraints on the behavior 
of a system, nicely complements model¬ 
ing approaches that specify behavior in 
a more local, operational fashion. Un¬ 
der certain technical conditions, any 
temporal logic formula can be system¬ 
atically translated into a watchdog, re¬ 
ducing the problem of verifying the com¬ 
plicated formula to that of establishing 
a much simpler property, such as reach¬ 
ability. The watchdog is then attached 
to the high-level controlling activity of 
the original model, resulting in a modi¬ 
fied model, and an appropriate exhaus¬ 
tive test is run. 

Actually, such verification need not 
be based solely on exhaustive execu¬ 
tions. Research into the theory and tech¬ 
nology of automatic verification of very 
large (but finite-state) systems against 
properties in temporal logic is already 
showing promising results. The tech¬ 
niques being developed in this area are 
far more subtle and efficient than brute- 
force exhaustive executions, and I be¬ 
lieve that they will eventually find their 
way into system analysis tools. This di¬ 
rection of work might very well bring 
true system verification into the living 
room, so to speak. 

Code generation. Even in its most 
advanced forms, executability is analo¬ 
gous to running conventional programs 
using interpretation. Complex systems 
are also amenable to the analog of com¬ 
pilation — that is, translating a model 
into runnable code in a lower level lan¬ 
guage. We call this ability code genera¬ 
tion, although the term is often used to 
denote the more humble ability to re¬ 


cast an unadorned functional descrip¬ 
tion as a template of code that contains 
empty-body procedures for the control¬ 
lers and the bottom-level activities. 
However, since the behavioral view does 
not exist (or is not covered) in such 
cases, the resulting code is but a scaffold 
that has to be enriched by handwritten 
code for the most crucial parts — nota¬ 
bly, those that depict the dynamics. It is 
thus like an automobile without an en¬ 
gine. The notion we have in mind here is 
far stronger. (Indeed, new terms, such 
as codifier and codification, might be 
more appropriate than code generator 
and code generation.) 

Using the vanilla approach terminol¬ 
ogy discussed earlier, we are talking 
about the translation of an entire con¬ 
ceptual model, that is, an activity hier¬ 
archy with all of its add-ons, including 
the controlling statecharts, into a pro¬ 
gramming language such as C, Modula 
2, or Ada. 

If the model contains bottom-level 
activities that were left unspecified, but 
have library routines or specially pre¬ 
pared code supplied by the user, this 
code can be linked to the code genera¬ 
tor’s output, thus completing the pic¬ 
ture. Since the behavioral aspects are 
an integral part of the conceptual model, 
they too are included in the translation. 
Hence, the resulting code can be run as is 
and, in terms of its dynamic semantics, is 
equivalent to the model itself. Needless 
to say, as in model execution, code gen¬ 
eration can be carried out on any syntac¬ 
tically legal portion of the model and at 
any stage of its development. 

Generated code is sometimes referred 
to as prototype code, since it reflects 
only the design decisions made in the 
process of preparing the conceptual 
model, and not decisions driven by im¬ 
plementation concerns. In many real¬ 
time applications, this code is not as 
efficient as the required real-time code. 
Nevertheless, it runs much faster than 
executions of the raw model itself, just 
as compiled code usually runs faster 
than an interpreted program. 

Using generated code. One of the 
main uses of code-generator output is in 
observing the system performing under 
close-to-real-world circumstances. For 
example, the code can be ported to, and 
executed in, the actual target environ¬ 
ment or, as is often the case in earlier 
stages, in a simulated version of the 
target environment. 
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The code can be linked to “soft” pan¬ 
els — graphical mock-ups of control 
boards, complete with images of display 
screens, switches, dials, and gauges — 
that represent the actual user interface 
of the final system. These panels appear 
on the screen and can be manipulated 
with mouse and keyboard. 

In the past few years, a number of 
companies have used this approach in 
design reviews involving customers and 
contractors, and it has proved to be 
extremely helpful — much more so than 
the typical documentation that accom¬ 
panies such reviews. 

It’s important to point out that these 
system interface panels are not driven 
by hastily written code prepared espe¬ 
cially for prototype purposes, but by 
code that was generated automatically 
from a model that is typically thorough¬ 
ly tested and analyzed before being sub¬ 
jected to code generation. Moreover, 
when parts of the real target environ¬ 
ment are available, they too can be linked 
to the code, and the runs become even 
more realistic. 

Code generation is thus to be used for 
goals that go beyond the development 
team, in that code-driven mock-ups can 
be used as part of the standard commu¬ 
nication between customer and contrac¬ 
tor or contractor and subcontractor. It 
is not unreasonable that such a running 
version of the system model be a re¬ 
quired deliverable in certain develop¬ 
ment stages. 

A good code-generation facility would 
also have a debugging mechanism, with 
which the user can trace the executing 
parts of the code back up to the system 
model. Breakpoints can be inserted to 
stop the run when specified events oc¬ 
cur, at which point the model’s status 
can be examined and elements can be 
modified on-the-fly before resuming the 

If substantial problems arise, chang¬ 
es can be made in the original model, 
which is then recompiled down into code 
and rerun. As in executions, trace files 
can be requested, recording crucial in¬ 
formation for future inspection. Carry¬ 
ing the analogy between compilation 
and code generation a step further, this 
ability is tantamount to source-level 
debugging. 

In addition to compiling, or codify¬ 
ing, the model itself, we can automati¬ 
cally produce code from specially pre¬ 
pared segments of behavior, such as 
watchdogs or test suites that are not 


As more and more 
code becomes final 
production code, 
the entire system 
comes closer to its 
final form. 


part of the model but are used to exe¬ 
cute and analyze it. For these, of course, 
the code generator output is actually 
final code. 

An interesting variation calls for re¬ 
placing high-level programming lan¬ 
guages as the target medium for gener¬ 
ated code by hardware description 
languages. A particular example is 
VHDL (which stands for VHSIC 
hardware description language, with 
VHSIC the abbreviation for very high¬ 
speed integrated circuit). In this way, 
hardware designers can also benefit 
from the virtues of the modeling and 
analysis techniques discussed above, and 
then translate their models into VHDL 
code, which can be subjected to silicon 
compilation or other appropriate pro¬ 
cedures. 

Verifying consistency between lev¬ 
els. Recall the process of preparing tiers, 
or strata, of conceptual models accord¬ 
ing to the physical model of the system. 
How can we establish the consistency of 
one level with the next? 

There are a number of ways in which 
model-analysis techniques can help. The 
basic idea is to redirect the efforts from 
the task of inspecting and debugging a 
single model to the task of comparing 
two models. This applies to all manner 
of analysis and verification: interactive, 
programmed, and exhaustive execution; 
watchdogs and temporal verification; 
and code generation. 

For example, we may execute the con¬ 
ceptual model prepared for a subsystem 
under the same conditions used to exe¬ 
cute the original model of the entire 
system, and compare the results. One 
way to do this involves preparing sce¬ 
narios for executing the new model di¬ 
rectly from trace files of executions run 
on the original model. Clearly, this is 


not as simple as it sounds, and much 
research on this topic is still needed. 

As far as code generation goes, we 
can often replace parts of the code gen¬ 
erated from the original model by code 
generated from the newly designed sub¬ 
system models. If the final system is to 
be implemented in software, this has 
the effect of gradually bringing the orig¬ 
inal prototype code down toward a real 
implementation. 

As subsystems are remodeled, their 
generated code is incorporated into the 
code that was generated one level high¬ 
er. As more and more of the code be¬ 
comes final production code, the entire 
system comes closer to its final form. 

It is not out of the question that this 
process will also become amenable to 
computerization. We can envision a user 
making restructuring decisions in the 
design stages (perhaps aided by an ex¬ 
pert system) and the tool taking over 
from there, reorganizing the generated 
code in new, more efficient ways that 
reflect those decisions. 

Combined with optimization proce¬ 
dures, which are badly needed and will 
hopefully be developed in the future, 
code generation has a chance to go far 
beyond prototyping, further justifying 
its role as the true complex system ana¬ 
log of conventional compilation. 


T he vanilla framework for system 
modeling outlined above is far 
from being universally accept¬ 
ed. Many of its facets are rooted in well- 
established and familiar ideas, but oth¬ 
ers are more recent and immature and 
require further work and experience. 

On some issues, there is little agree¬ 
ment among researchers and practi¬ 
tioners, such as how to best approach 
the specification of behavior. I believe 
that the general framework is a good 
one and that there are also adequate 
proposals for behavioral specification. 
However, even the overall mold could 
easily turn out to be inadequate. 

If it does not become the accepted 
analog of good old vanilla program¬ 
ming, then some other approach will. 
The precise form the winning effort takes 
on will be secondary, though I am fully 
convinced that reactive behavior will be 
one of its most crucial and delicate com¬ 
ponents, rigorous semantics included, 
and that visuality will play center stage. 
From this basic framework will evolve 
more specialized and exotic ones, for 
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which appropriate modeling languages 

I will be designed and implemented and 

methods and guidelines conceived and 
mastered. 

Things are far clearer in the analysis 
realm, where most of the abilities we 
have discussed are, to some extent, in¬ 
dependent of the idiosyncrasies of the 
particular modeling approach. I believe 

I that system development tools that lack 

powerful execution and code-genera¬ 
tion capabilities will all but disappear. 

Whichever approach people ultimate¬ 
ly use to conceptualize and model their 
[ systems, the ability to thoroughly exe¬ 

cute the resulting models and to com¬ 
pile them down into conventional high- 

I level code will become indispensable. 

In a way, this too is vanilla. I believe 
that in time more exotic kinds of exe- 
cutability features will emerge, such as 
ones tailored to carry out timing and 
performance analysis, gather statistics, 
or compare the behavioral aspects of 
separate models. 

A number of research directions 

I present themselves, and in some there 

is already a promising body of work. 
Among the most important are 


The current situation 
and prospects for 
significant improvement 
indicate that we are at 
the start of a new and 
exciting era. 


(1) improving the techniques for gen¬ 
erating high-quality code from 
conceptual models, and provid¬ 
ing (semi)automated help to make 
design decisions in the process, 
and 

(2) enabling truly useful computer¬ 
ized verification of conceptual 
models against global constraints. 

One of the crucial ingredients for suc¬ 
cess in these areas is extensive cooper¬ 
ation and collaboration of researchers 


in software and systems engineering with 
those in compilers, optimization, and 
heuristics for item (1) and in logic, se¬ 
mantics, and verification for item (2). 

The current situation and the pros¬ 
pects for significant improvement indi¬ 
cate that we are at the start of a new and 
exciting era. ■ 
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The 3DP: 

A Processor Architecture 
for Three-Dimensional 
Applications 


Yulun Wang, Amante Mangaser, Partha Srinivasan,* 

and Steve Jordan, Computer Motion 

Steven Butner, University of California, Santa Barbara 


Many computational 
problems that involve 
objects in the physical 
world require 
numerous calculations 
on 3D vectors. This 
article describes a 
parallel-computing 
architecture that 
targets these problems. 


A 1 large class of problems share a common three-dimensional numerical 
j structure and require numerous calculations on 3D vectors. In a general 

.I sense, this structure is intrinsic to problems that deal with representing 

and manipulating objects in the physical world. Example computing applications 
include dynamic simulation (such as automobile suspension modeling and flight 
simulation), molecular modeling, animation, 3D graphics, and robotics. 

The 3DP, for 3-Dimensional Processor, is a parallel-computing architecture that 
targets these problems. It includes a hardware and software design that gives users 
an intuitive 3D object-oriented programming environment. It uses a C++ optimiz¬ 
ing compiler to create assembly instructions that exploit underlying hardware 
capabilities for parallel processing. 

The 3DP architecture differs from traditional scalar architectures in that it 
operates directly on vectors. It differs from general parallel architectures in that it 
can solve problems that predict the behavior of highly coupled systems, and it 
differs from vector architectures in that it runs efficiently on length-3 vectors. 

Many different processor architectures have been developed to solve computa¬ 
tional problems. General-purpose designs are most prevalent because they can be 
applied to a wide range of applications. They can handle very different computa¬ 
tion problems — from database management to scientific applications — with an 
acceptable degree of efficiency. 

General-purpose architectures keep their flexibility by operating efficiently on 
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the smallest common denominator to 
all classes of problems. For example, 
nearly all applications include the basic 
data types of byte, integer, and floating¬ 
point scalar. By concentrating on these 
data types in combination with the op¬ 
erations most frequently performed on 
them, computer designers can optimize 
for general-purpose operations like 
managing program-control flow and ad¬ 
dressing memory. 

If a class of problems with a particular 
characteristic is identified and this class 
encompasses enough applications, a spe¬ 
cialized processor architecture can be 
justified. For example, designers found 
that digital signal processing intrinsi¬ 
cally involved many consecutive multi¬ 
ply and accumulate operations. There¬ 
fore, they developed digital signal pro¬ 
cessors with a fast multiply-accumulate 
unit to give direct hardware support to 
this intrinsic characteristic. Interesting¬ 
ly enough, once DSPs were created, 
they were immediately found to be use¬ 
ful in other application areas as well. 

Vector architectures form the basis 
for a class of computers developed for 
numerically intensive applications. Two 
areas that rely on fast vector processing 
are finite-element analysis and the si¬ 
multaneous solution of large sets of 
partial differential equations. Supercom¬ 
puters attack these problems with ex¬ 
tensively pipelined execution units. 
When these problems are formulated 
into large matrix equations, a long vec¬ 
tor pipeline increases execution speed 
to solve them efficiently. However, for 
vector architectures to work efficiently, 
they must operate on a relatively long 
vector length. 1 

General-purpose and DSP architec¬ 
tures have not exploited the intrinsic 
structure of problems that require nu¬ 
merous calculations on 3D vectors, and 
the long pipelines of typical vector ar¬ 
chitectures prevent fast execution of 
short vectors. The 3DP architecture 
uniquely attacks an instruction-set level 
of parallel processing, executing 3D ap¬ 
plications up to five times faster than on 
Sun4 Sparc and Mips R3000 architec¬ 
tures. 

In this article we describe the 3DP 
architecture, its software environment, 
and its performance results. We also 
describe an attached computer that 
employs a discrete implementation of 
the 3DP architecture; this computer was 
designed for real-time motion control 
and simulation applications. 


Approaches to parallel 
processing 

Parallel processing reduces a task’s 
execution time by solving multiple parts 
of the problem at the same time. Re¬ 
searchers have spent a great deal of 
energy over the past several decades 
finding ways to exploit various degrees 
of parallelism, from very coarse to very 
fine. An example of coarse-level paral¬ 
lelism is multiple workstations cooper¬ 
atively and simultaneously solving the 
same problem, whereas an example of 
fine-level parallelism might involve pipe¬ 
lining instruction execution at the pro- 
cessor-instruction-set level. There are 
both coarser and finer grains of paral¬ 
lelism than these two examples; but even 
within these boundaries, many levels of 
granularity exist. Parallel processing with 
multiple computers, multiple processors, 
super-scalar processing, and various 
degrees of pipelining have all been used 
successfully. 2 

The best parallel-processing methods 
for increasing an application’s execu¬ 
tion speed depend on the application’s 
characteristics. For example, the data 
dependencies of a problem influence 
the optimum number of stages in the 
execution pipeline and the allowable 
communication overhead for interpro¬ 
cessor data transfer. In some cases, loose¬ 
ly coupled multiprocessors can ade¬ 
quately increase the execution speed. 
In other cases, only tightly coupled pro¬ 
cessors can efficiently exploit a prob¬ 
lem’s intrinsic parallelism. 

The goal of parallel processing archi¬ 
tecture design is to maximize concur¬ 
rent execution yet remove the user from 
the tedious task of managing the paral¬ 
lelizing process. The user should be able 
to write a single sequential program, 
and the computer’s system software 
should handle the program’s parallel 
execution automatically. While finer 
levels of parallel processing, such as 
instruction pipelining and super-scalar 
processing, have been successfully de¬ 
ployed under this paradigm, coarser 
grain parallellism still requires the user 
to assist the computer system in parti¬ 
tioning the problem. 

The target problem 

Three-dimensional applications cov¬ 
er a broad spectrum of problem types. 


Medical imaging requires numerous 3D 
distance calculations. Computer graph¬ 
ics abounds with 3D transformations 
and clipping operations. Simulating 
physical systems requires the solution 
of complex dynamic and kinematic re¬ 
lations. Robotics, scientific visualiza¬ 
tion, molecular modeling, and anima¬ 
tion are other 3D applications. Speed is 
a critical factor in all these areas; it is of 
the utmost importance in many real¬ 
time computing simulations that must 
generate results that appear realistic. 

All these applications require a large 
number of 3D calculations to determine 
the relations between various physical 
quantities — for example, the distance 
between two points, the relation be¬ 
tween an angular and a translational 
velocity, and the resultant acceleration 
due to an applied force. Some frequent¬ 
ly used equations follow: 

P, = P, + P 

V = to x R 

A„ = oo x (co x R) 

A, = a x R 

F = mA 
M = la 

where 

P,, P 2 , and P, = position vectors 

V = linear velocity vector 
co = angular velocity vector 
A = acceleration vector 

A n = normal acceleration vector 
A, = tangent acceleration vector 
R = radius vector 
F = force vector 
M = moment vector 
a = angular acceleration vector 
I = inertia tensor (3x3 matrix) 
m = mass (scalar) 

These equations show how fundamen¬ 
tal the 3D-vector data type is for prob¬ 
lems that deal with modeling and simu¬ 
lating real-world phenomena. More 
complex relations, such as the equa¬ 
tions of motion for complex mechanical 
systems, are derived from these basic 
equations. The intuitive reason for this 
3D structure is that these mathematical 
expressions explain the dimensions and 
motion of 3D bodies in 3D space. Posi¬ 
tion, velocity, acceleration, force, and 
moment are all 3D-vector quantities. 

The homogeneous transformation is 
a commonly used representation that 
combines vector translation, rotation, 
and scaling all into a single matrix oper- 
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Figure 1. The 3DP architecture. 


ation. Even though this oper¬ 
ation is presented as a four- 
by-four matrix, it can be de¬ 
composed into four 3D vectors 
and a single scalar. In the ex¬ 
ample below, the n,o,a, and p 
columns represent the four 
vectors: n (normal), o (orien¬ 
tation), a (approach), and p 
(position). 

Sj _ n, Oj a t Pj tj 

s k n k p k a k p k t k 

1 J [ 0 0 0 1 JL 1. 

The scaling between vectors 
can be changed by using a num¬ 
ber other than unity in the 
lower right element of the four- 
by-four matrix. 

The 3DP 
architecture 

The 3DP architecture gives 
users the appearance of a sin¬ 
gle-processor, sequential-execution en¬ 
vironment, while it exploits parallel pro¬ 
cessing on 3D applications by targeting 
the intrinsic 3D-vector data type. Note 
that this approach complements other 
parallel-processing techniques. Even 
though most calculations in 3D applica¬ 
tions operate on 3D vectors, there is 
always a significant number of scalar 
computations as well. The 3DP archi¬ 
tecture accelerates 3D computations 
without sacrificing scalar performance, 
which could easily offset the gain from 
fast 3D processing — as, in fact, hap¬ 
pens with highly pipelined vector pro¬ 
cessors. 

The 3DP targets length-3 vectors by 
providing a three-wide register file and 
three parallel execution units that can 
operate simultaneously on all three vec¬ 
tor components. Figure 1 shows a sche¬ 
matic of the 3DP architecture and how 
it connects to memory and I/O modules 
in our current implementation. This par¬ 
allel arrangement allows individual use 
of the execution units for scalar opera¬ 
tions. The architecture supports 3D vec¬ 
tor operations, scalar operations, and 
3D vector-scalar operations with a high 
degree of efficiency. (A good example 
of a vector-scalar operation is Newton’s 
second law: F = mA, where F and A are 


3D-vector quantities and m is a scalar.) 

Referring to Figure 1, the data path 
can operate simultaneously on two 
three-component vectors. The data path 
originates (and ends) at the three-wide 
vector register file, where each vector 
register has an i, j, and k component. 
The instruction set is organized to allow 
access to any vector register either as a 
single entity (for example, using the 
notation RO) or to its individual com¬ 
ponents (using the notation RO.i to 
represent the ith component of register 
RO). 

Every instruction executes in four 
stages: (1) instruction fetch, (2) oper¬ 
and fetch, (3) instruction execute, and 
(4) operand store. Since operands are 
fetched during the second cycle and 
stored on the fourth, there is a one- 
cycle data dependency. The 3DP uses a 
Flarvard architecture, 3 which separates 
program and data memory to allow si¬ 
multaneous instruction and data fetches, 
thereby eliminating contention during 
memory accesses and increasing execu¬ 
tion speed. Another advantage of the 
Harvard design is that program execu¬ 
tion speed is more deterministic, which 
is important for real-time applications. 

The current 3DP implementation 
holds 64 vector registers, each with three 


32-bit components. The 
number 64 was not derived 
as an optimal number; rath¬ 
er, it was set by the config¬ 
uration of off-the-shelf reg¬ 
ister-file components. Since 
each vector register can be 
replaced by three scalar reg¬ 
isters, the current imple¬ 
mentation can hold up to 64 
vectors, 192 scalars, or any 
combination of the two. The 
allocation of registers can 
change constantly through¬ 
out program execution. 

The 3DP is a register-to- 
register architecture, which 
facilitates fast clock speed 
and a simple instruction set. 4 
The register file has four 
ports, two dedicated for 
reading and two for writ¬ 
ing. A multiplexer connects 
the output ports to the exe¬ 
cution unit. One of the in¬ 
put ports comes from the 
external data bus, while the 
other one returns the oper¬ 
ands from the execution unit 
via a multiplexer. The pri¬ 
mary purpose of the register file is to 
store data operands. However, it also 
serves a secondary purpose: Because 
the processor has an internal vector ar¬ 
rangement, the register file provides an 
interface between the processor’s ex¬ 
ternal single-width data bus and the 
internal three-wide execution bus. A 
single-width external bus is consistent 
with other microprocessor architectures 
and allows the use of standard interfac¬ 
ing techniques to connect peripherals 
(for example, memory and I/O ports). 

Every functional instruction begins 
execution by fetching the source oper¬ 
ands from the register file. These oper¬ 
ands enter the three-wide execution unit 
via three of six possible data paths. The 
execution unit consists of three arith¬ 
metic-logic units and three floating-point 
processing units connected in parallel 
“columns,” with each column consist¬ 
ing of one ALU and one FPU. Two data 
paths connect each column of the vec¬ 
tor register file to the corresponding 
execution unit column. 

A source multiplexer (shown in Fig¬ 
ure 1) supports intercolumn operations. 
For example, it provides a path for add¬ 
ing RO.i to Rl.k. Intercolumn opera¬ 
tions are used in both vector and scalar 
instructions. After the desired instruc- 
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RFMUR Rl, R2, R3 

rotate vector Rl right 1 component, 
floating-point vector multiply with R2, 
rotate result right 1 component and store in 

R3 

LFMUL R1,R2,R4 

rotate vector Rl left 1 component, floating 
point vector multiply with R2, rotate result 
left 1 component and store in R4 

NOP 

no operation, pipeline dependency in R4 

FSU R3, R4, R3 

floating-point vector subtract of R4 
from R3 with the result stored in R3 

Note that these are vector component rotates (that is, for a right rotate: ith vector component -> 

/th position, ;'tb vector component -> &th position , fcth vector component -»ith position). 


Figure 2. Cross-product operation (R3 = R1 x R2). 


FMU Rl, R4.i, Rl 

vector-scalar floating-point multiply 

FMU R2, R4.j, R2 

vector-scalar floating-point multiply 

FMU R3,R4.k, R3 

vector-scalar floating-point multiply 

FAD Rl, R2, R2 

vector addition 

NOP 

no operation, pipeline dependency 

FAD R2, R3, R5 

vector addition 


Figure 3. Matrix-vector multiply (vector rotation). 


tion executes, the destination multiplex¬ 
er can alter the order of the operands 
before storing them in the register file. 
The destination multiplexer can also 
perform scalar calculations involving in¬ 
tercolumn operations. The destination 
and source multiplexers give the 3DP 
its unique capability of supporting fast 
3D geometric processing while main¬ 
taining good scalar performance. 

The vector cross product is a common 
3D geometric operation that illustrates 
this capability. For example, the cross 
product is used to calculate the deriva¬ 
tive of a vector in a rotating coordinate 
frame or to find a vector normal to a 
plane. To compute R3 = R1 x R2, we 
would need to evaluate 

R3.i = Rl.j R2.k - Rl.k R2.j 
R3.j = Rl.k R2.i -Rl.iR2.k 
R3.k = Rl.i R2.j - Rl.j R2.i 

The 3DP computes these operations 
with the four assembly-language instruc¬ 
tions in Figure 2. The first instruction 
computes the first three partial prod¬ 
ucts of R3.i, R3.j, and R3.k and stores 
the result in vector register R3. The 
second instruction computes the sec¬ 


ond three partial products and stores 
the results in a temporary vector regis¬ 
ter R4. The source and destination mul¬ 
tiplexers are used to combine vector 
components appropriately. The third 
instruction, a no-operation, is neces¬ 
sary because of the pipeline dependen¬ 
cy created by R4, which results from the 
second instruction and is used in the 
fourth. Finally, the fourth instruction 
subtracts the two sets of partial prod¬ 
ucts and stores the answer in R3. Since 
the 3DP completes one instruction ev¬ 
ery cycle, a floating-point vector cross 
product executes in four cycles. Anoth¬ 
er cycle is needed before the cross- 
product result is available for further 
calculations. 

Another common 3D operation is 
vector rotation. It is generally performed 
by multiplying a vector with a rotation 
matrix as shown below: 

St n, o, at t, 

_ s k. _ n kPk a k__ t k_ 

Figure 3 lists the 3DP assembly-instruc¬ 
tion sequence to calculate a matrix-vec¬ 


tor multiply. The rotational matrix col¬ 
umns, n, o, and a, are stored in vector 
registers Rl, R2, and R3; and the vector 
to be rotated, t, is stored in R4. The final 
result, s, is placed in R5. 

It takes six cycles to execute a matrix- 
vector multiply. Note that the first 
three instructions in Figure 3 are scalar- 
vector multiply instructions. We can gen¬ 
eralize a vector rotation computation to 
a homogeneous transformation by aug¬ 
menting the sequence with a single vec¬ 
tor. Hence, the 3DP performs homoge¬ 
neous transformations in seven cycles 
(assuming a unity scaling factor). 

The presence of three simultaneous 
execution paths is a unique 3DP fea¬ 
ture. One difficulty created by a plural¬ 
ity of execution units is that three sets of 
condition flags exist. The 3DP uses con¬ 
dition flags for control flow operations, 
such as conditional branch instructions. 
The problem is that the conditional 
branch instruction must know which of 
the three sets of flags to use for its test. 
To solve this problem, we constrained 
assembly-language program structure 
by asserting that the condition-setting 
instruction must immediately precede 
all conditional branch operations. With 
this constraint, we always knew the rel¬ 
ative distance between the condition¬ 
setting instruction and the conditional 
jump instruction, and could design the 
hardware to select the appropriate flag 
automatically. 

We considered many interesting uses 
for the multiple sets of condition flags. 
For example, it is possible for one in¬ 
struction to determine whether or not a 
vector is zero by offering a branch-vec¬ 
tor zero operation that would test the 
three zero flags simultaneously. Anoth¬ 
er possibility is to determine if a vector 
lies in a particular quadrant by provid¬ 
ing vector quadrant tests. In our current 
implementation, we decided to provide 
the typical scalar test conditions and a 
zero vector test. 

The 3DP is the second generation of 
an earlier design — the robotic proces¬ 
sor. The robotic processor is the key 
computational element of a heteroge¬ 
neous multiprocessor system called 
Robotic Instruction Processing System 
(RIPS). 5 The 3DP architecture was de¬ 
veloped with the same 3D philosophy 
as the robotic processor, but with an 
improved design. One major change is a 
completely orthogonal data path, which 
gives each register the same functional¬ 
ity. In other words, any register can be 
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used for any of the assembly-language 
instructions. Orthogonality is very im¬ 
portant when developing a high-level 
language compiler for a processor ar¬ 
chitecture. 6 We discovered that non¬ 
orthogonalities in the robotic processor 
design frequently prevented our com¬ 
piler from generating efficient assem¬ 
bly code. 

Object-oriented 
programming on 
the 3DP 

The successful use of any hardware 
architecture requires a good method 
for programming the system. One meth¬ 
od is to define a custom language with 
its own syntax and semantics tailored to 
fit a specific architecture. This approach 
may benefit implementation, but it has 
the significant disadvantage of requir¬ 
ing users to learn a new custom lan¬ 
guage. Another approach is to extend 
an existing standard language by add¬ 
ing specialized features that exploit the 
uniqueness of the architecture. In our 
case, this approach would have required 
extensions of both syntax and seman¬ 
tics to include a “machine” 3D-vector 
data type. Once again, the disadvantage 
is that the resulting language is no long¬ 
er standard. A third approach is to de¬ 
velop a vectorizing compiler for a stan¬ 
dard, user-extensible language. The 
compiler would need to be sophisticat¬ 
ed enough to automatically detect sec¬ 
tions of code amenable to vectoriza- 
tion. This approach would require a 
major compiler effort. 

One final approach — the one we 
used for the 3DP — is to begin with a 
language that includes user-defined data 
types, then provide direct compiler sup¬ 
port so the hardware can exploit these 
types. Using this approach, we devel¬ 
oped a high-level object-oriented pro¬ 
gramming environment that lets the user 
program 3D applications intuitively and 
lets the compiler exploit the hardware’s 
underlying parallel-processing capabil¬ 
ities. We targeted the Free Software 
Foundation’s GNU C++ optimizing 
compiler 7 to support high-level object- 
oriented programming with the 3DP 
architecture. The C++ language allows 
the user to define new data types — for 
example, 3D vectors — and to provide 
the compiler with an entire set of oper¬ 
ators and functions that work on the 



Figure 4. Rotating rigid body. 


new data types. This is an ideal solution 
because it leaves the standard language 
syntax and semantics unchanged and 
lets the user write programs with a data 
type that the underlying machine can 
manipulate efficiently. C++ is a rela¬ 
tively new object-oriented programming 
language 8 that is rapidly gaining in pop¬ 
ularity. The object-oriented paradigm 
facilitates higher levels of abstraction 
than procedural languages do, and it is 
well suited for manipulating real-world 
objects. 

The back end of the GNU optimizing 
C++ compiler is retargetable, so instead 
of writing a compiler from scratch, 
we retargeted the GNU compiler to 
generate code for the 3DP architecture. 
The object-oriented features of C++ 
allow us to generate efficient vector 
code for 3DP execution. By introducing 
a 3D vector class, VEC3, the program¬ 
mer can directly manipulate such 3D 
variables as positions, velocities, and 
forces. 

Retargeting the GNU compiler to a 
new architecture generally requires de¬ 
veloping a “machine description file” 
that tells the compiler the architecture’s 
capabilities. However, the 3DP is unique 
in the sense that it can directly store and 
manipulate 3D vectors. Consequently, 
to exploit the GNU compiler’s sophisti¬ 
cated register optimizations, we incor¬ 
porated a new VEC3 machine-mode 
into the compiler. Inserting this mode 
was the most complex and time-con¬ 
suming part of the retargeting effort. 
The resulting compiler operates as well 
with VEC3s as it does with floats, inte¬ 
gers, and other basic types. This is crit¬ 
ical to efficient compilation. 


Programming the 3 DP 
in C++ 

Since the mathematical explanation 
of the motion of physical systems is 
derived from fundamental 3D-vector 
quantities, the VEC3 data type allows 
the programmer to implement motion 
control algorithms in an intuitive way. 
The programmer can easily comprehend 
and work with positions, velocities, ac¬ 
celerations, and other 3D physical quan¬ 
tities. Furthermore, by writing code 
based on VEC3 objects, the program¬ 
mer is showing the compiler where the 
intrinsic 3D parallelism of the problem 
lies. The resulting paradigm is a power¬ 
ful, conceptually simple programming 
methodology that generates highly effi¬ 
cient code for execution on the underly¬ 
ing hardware. 

Operator overloading is an attractive 
feature of C++ and useful for data ab¬ 
straction. It lets the user define the se¬ 
mantics for operators on new data types. 
In our case, operator overloading is used 
not only to define semantics, but also to 
teach the compiler how to manipulate 
VEC3 objects efficiently. We use oper¬ 
ator overloading to define addition, sub¬ 
traction, and multiplication. For exam¬ 
ple, we define vector addition to add 
the i components together, the j compo¬ 
nents together, and the k components 
together. The overloaded operator also 
knows how to use appropriate vector 
assembly-language instructions to ex¬ 
ploit the 3DP’s parallel-processing ca¬ 
pabilities. We also overload useful 
combinations of VEC3 objects and 
scalars. For example, we define the ad¬ 
dition of a VEC3 object to a scalar so 
that the scalar value is added to each 
vector component in a single 3DP in¬ 
struction. 

The three components of a VEC3 
object are individually accessible using 
array notation (for example, s[0] is the 
ith component, s[l] is the y'th compo¬ 
nent, and s[2] is the kth component, as 
shown in Figure 1). Consequently, vec¬ 
tor components can be individually used 
for scalar operations. We have already 
shown that accessing vector components 
is useful in matrix-vector multiplies (see 
the first three instructions of Figure 3). 

To illustrate how convenient VEC3s 
are to use, we can write a simple pro¬ 
gram that calculates the acceleration of 
a fixed point within a rotating rigid body. 
Figure 4 shows this graphically. The 
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equation that calculates the accelera¬ 
tion of point p is as follows: 

a = a x r + co x (to x r), 

where a is the acceleration vector of 
point p, co is the angular velocity of the 


rigid body, a is the angular acceleration 
of the rigid body, and r is the vector 
from co axis to p. 

Figure 5 presents a C++ program that 
evaluates this equation. To reduce the 
amount of code in this example, we 
have listed only the main routine. Fig¬ 


ure 6 demonstrates how simple and di¬ 
rect the 3DP assembly code is for equa¬ 
tions involving 3D vectors and scalars. 
The overloaded functions listed in the 
“/usr/local/include/3dv.h” file define to 
the compiler how to add and multiply 
vectors, as well as how to process com- 


Figure 5. C++ program 
source code. 

Figure 6. Assembly code for 
3DP compiler. 

Figure 7. Assembly code for 
Sparc compiler. 


#include "/usr/local/include/3dv.h" 

#include "/usr/local/include/rpc3dp.h" 


VEC3 


alpha, r, accel; 

w.init (1.0, 2.0, 3.0); 
alpha.init(4.0, 5.0, 6.0); 
r.init(7.0, 8.0, 9.0); 


// calculate acceleration vector 

accel = cross (alpha, r) + cross 


// declare variables 

// initialize angular velocity 
// initialize angular acceleration 
// initialize r vector 




// print resulting acceleration 

printf("\naccel is: %f, %£, 


accel.s[l), accel.s[2]); 


NOP 


RTN,-4 (SP) 
#-14,SP,SP 


; function prologue 
; end function prologue 


LD _LC 5, % 0 . j 

LD _LC6,%0.k 

LD _LC7,*l.i 

ST %0.j, (%0.i) 

ST %0.k,1(»0.i) 

ST ' %1. i, 2 (%0 . i) 

ADD #-6,FP,%0.i 

LD _LC8,%0.j 

LD _LC9,%0.k 

LD _LC10,%l.i 

ST %0. j, (%0.i) 

ST %0.k,1(%0.i> 

ST %1.i,2 (%0 . i) 

ADD #-9,FP,%0.i 

LD _LC11,% 0.j 

LD _LC12,%0.k 

LD _LC13,%1.i 

ST %0.j,(%0.i) 

ST %0. k, 1 (%0 . i) ' 

ST %1.1,2 (%0.i) 

LD -6(FP),%16.i ; load 

LD -6+1(FP),%16.j 

LD -6+2(FP),%16.k 

LD -9(FP),%17.i ; load 

LD -9+1(FP),%17.j 

LD -9+2(FP),%17.k 


alpha 


FRMULR %16,%17,%18 ; crossfalpha, r) 

FLMULL, %16,%17,%16 


FSUB %18,%16,%16 

LD -3 (FP), %18. i ,- load vector w 

LD -3+1(FP), %18.j 

LD -3+2(FP) , %18.k 


FRMULR %18,%17,%19 ; cross(w, r) 

FLMULL %18,%17,%17 


FSUB %19,%17,%17 


NOP 

FRMULR %18,%17,%19 
FLMULL %18,%17,%17 

FSUB %19,%17,%17 
NOP 

FADD %16,%17,%16 
SUB SP,#1,SP 

NOP 

ST %16.k, (SP) 

MOV %16.j,%0.k 

MOV %16.i,%0.j 

LD #[_LC14],%0.i 

JSR _printf 

ST FP,-5(SP) 

ADD #1,RTN,RTN 

ADD #-5,SP,FP 

ADD #1,SP,SP 

LD l.(FP) , RTN 




final vector add 


function epilogue 


ADD #5,FP,SP 

LD (FP), FP 

NOP ; end function epilogue 



















binations of vectors and scalars. Be¬ 
cause this file provides the implementa¬ 
tion details, the end user need not be 
concerned with them. Therefore, the 
user can program at a relatively high 
level of abstraction. The primary con¬ 
cern is implementation of the algorithm. 


Figure 7 shows the significantly greater 
amount of assembly code generated by 
the Sparc C++ compiler to perform the 
same calculation. 

Other 3D classes can be built from 
VEC3s. We have developed a complete 
set of 3D operations for the following 


four classes: 3D vectors, rotational ma¬ 
trices, homogeneous transformations, 
and quaternions. The class that sup¬ 
ports rotational transformations is called 
ROT. A ROT is a 3-by-3 matrix made 
from three VEC3s whereby each VEC3 
stores a different column of the matrix. 


_VEC3_PSVEC3: 

!#PROLOGUE# 0 
save %sp,-112,%sp 
!fPROLOGUE# 1 
orcc %iO,%gO,%ol ! 


L2: 


call builtln new,0 
mov 12,%o0 
mov %o0,%ol 

sethi %hi(LCO),%o0 
or %lo(LCO),%o0,%o0 
Id [%o0],%o2 
st %o2,[%ol] 

Id [%o0], %o2 
st %o2, [%ol+4] 

Id [%o0],%o2 
st %o2,[%ol+8] 


.align 4 
.proc 1 

_VEC3_PSVEC3_SF_SF_SF: 

!#PROLOGUE# 0 
save %sp,-112,%sp 
! #PROLOGUE# 1 
mov %i0,%o0 
mov %il,%10 
mov %12,%11 



call _builtin_new,0 

mov 12,%o0 

st %10,[%o0] 
st %11, [%o0+4] 
st %12,[%o0+8] 
mov %o0,%i0 



!#PROLOGUE# 0 


save %sp,-336,%sp 
!#PROLOGUE# 1 
add %fp,-32,%11 
call _VEC3_PSVEC3,0 
mov %11,%o0 


call 

call 



rEC3 PSVEC3,C 


VEC3 PSVEC3,C 


sethi %hi(LC2),%gl 
Id [%gl+%lo(LC2)],%o0 
sethi %hi(LC3),%gl 
Id [%gl+%lo(LC3)],%ol 
sethi %hi (LC1),%gl 
Id [%gl+%lo(LC1)] , %17 
st %17,[%11] 
st %o0, [%11+4] 
st %ol, [%ll+8] 
sethi %hi (LC5),%gl 


Id [%gl+%lo(LC5)],%o0 
sethi %hi(LC6),%gl 
Id [%gl+%lo(LC6)],%ol 
sethi %hi (LC4),%gl 
Id [%gl+%lo(LC4)],%17 
st %17, [ %14] 
st %o0, [%14+4] 
st %ol,[%14+8] 
sethi %hi (LC8),%gl 
Id [%gl+%lo(LC8)],%o0 
sethi %hi(LC9),%gl 
Id [%gl+%lo(LC9)],%f5 
sethi %hi (LC7),%gl 
Id [%gl+%lo(LC7)],%17 
st %17, [ %13] 
st %o0,[%13+4] 
st %f5,[%13+8] 
add %fp,-144,%12 
mov %12,%15 
Id [%14+4],%f6 
fmuls %f6,%f5,%f2 
Id [% 13-4-4 ], %f 9 
Id [%14+8],%f3 
fmuls %f9,%f3,%f8 
Id [%13],%f7 
fmuls %f7,%f3,%f4 
Id [%14],%f3 
fmuls %f3,%f5,%f5 
fmuls %f3,%f9,%f3 
fmuls %f7,%f6,%f7 
mov %12,%o0 
fsubs %f2,%f8,%flO 
st %flO, [%fp— 4] 

Id [%fp-4],%ol 
fsubs %f4,%f5,%flO 
st %flO,[%fp-4] 

Id [%fp-4],%o2 
fsubs %f3,%f7,%flO 
st %flO,[%fp-4] 

Id [%fp-4],%o3 

call _VEC3_PSVEC3_SF_SF_SF, 0 
nop 

add %fp,-192, %15 
add %fp,-176,%14 
mov %15,%16 
Id [%ll+4],%f5 
Id [%13+8],%f9 
fmuls %f5,%f9,%f2 
Id [% 134-4 ], %f 8 
Id [% 114-8 ], %f3 
fmuls %f8,%f3,%f7 
Id [%13],%f6 
fmuls %f6,%f3,%f4 
Id [%11],%f3 
fmuls %f3,%f9,%f9 
fmuls %f3,%f8,%f3 

mov %15,%o0 
fsubs %f2,%f7,%f10 
st %fl0,[%fp-4] 

Id [%fp— 4],%ol 
fsubs %f4,%f9,%f10 
st %fl0,[%fp-4] 

Id [%fp-4],%o2 
fsubs %f3,%f6,%f10 
st %fl0,[%fp-4] 

Id [%fp-4],%o3 

call _VEC3_PSVEC3_SF_SF_SF, 0 



Id [% 114-4 ] , %f 6 
id [%15 + 8],%f9 
fmuls %f6,%f9,%f2 
Id [%15+4],%f8 
Id [%ll+8],%f3 
fmuls %f8,%f3,%f7 
Id [%15],%f5 
fmuls %f5,%f3,%f4 
Id [%11],%f3 
fmuls %f3,%f9,%f9 
fmuls %f3,%f8,%f3 
fmuls %f5,%f6,%f5 
mov %14,%o0 
fsubs %f2,%f7,%f10 
st %fl0,[%fp-4] 

Id [%fp-4],%ol 
fsubs %f4,%f9,%fl0 
st %f10,[%fp-4] 

Id [%fp-4],%o2 
fsubs %f3,%f5,%f10 
st %fl0,[%fp-4] 

Id [%fp-4],%o3 

call _VEC3_PSVEC3_SF_SF_SF,0 
nop 

mov %10,%11 
Id [%12],%f2 
Id [%14],%f5 
Id [%12+4],%f3 
Id [%14+4],%f6 
Id [% 124-8 ] , %f 4 
Id [% 144-8 ] , %f 7 
mov %10,%o0 
fadds %f2,%f5,%f10 
st %f10,[%fp-4] 

Id [%fp-4],%ol 
fadds %f3,%f6,%f10 
st %fl0,[%fp— 4] 

Id [%fp-4],%o2 
fadds %f4,%f7,%fl0 
st %fl0, [%fp— 4] 

Id [%fp-4],%o3 

call _VEC3_PSVEC3_SF_SF_SF, 0 
nop 

Id [%fp-80] , %f2 
Id [%fp-76],%f3 
Id [%fp-72],%f4 
fstod %f4,%f4 
sub %sp,8,%sp 
st %f4,[%fp-4] 

Id [%fp-4],%o5 
%f5. r%fD-4i 
Id [%fp-Tt,■%!7 
st %17, [%sp+92] 
sethi %hi(LC10),%o0 
or %lo(LC10),%o0,%o0 
fstod %f2,%fl0 
std %fl0,[%fp-8] 

Id [%fp-4],%o2 
Id [%fp-8],%ol 
fstod %f3,%fl0 
std %fl0,[%fp-8] 

Id [%fp-4],%o4 
Id [%fp-8],%o3 
call _printf,0 















Figure 8. The 3DP attached processor. 


The names of the vectors are n (nor¬ 
mal), o (orientation), and a (approach), 
consistent with standard mathematical 
terminology. For example, 


These columns can be individually 
accessed as 3D vectors. For example, if 
a ROT ttt was declared, ttt.n refers to 
column n of the matrix. Since each com¬ 
ponent of a vector can be accessed inde¬ 
pendently, ttt.n.s[0] refers to the ith 
component of column n of matrix ttt. 

3DP performance 

The 3DP architecture has been im¬ 
plemented as an attached processor for 
real-time 3D processing (as shown in 
Figure 1). Figure 8 is a photograph of 
the board. Example application areas 
for this system are advanced motion 
control, dynamic simulation, 3D mod¬ 
eling, and 3D vision. Our current ver¬ 
sion implements the 3DP architecture 
using off-the-shelf discrete logic and is 


clocked at 10 MHz. Because one in¬ 
struction completes every cycle on three 
parallel execution units, the peak exe¬ 
cution rate is 30 Mflops. 

Table 1 shows the system’s perfor¬ 
mance on basic arithmetic operations. 
Note that the scalar addition, subtrac¬ 
tion, and multiplication take the same 
computational time as their 3D coun¬ 
terparts. These times assume fully pipe¬ 
lined operation. Elementary functions, 
such as trigonometric functions, square 
root, and logarithms, which are not 3D 
calculations, rely on the processor’s sca¬ 
lar speed. We developed a complete 
math library that includes most of the 
elementary functions and have achieved 
adequate results. For example, a sine or 
a cosine function takes 7 microseconds 
to evaluate. 

To calibrate the 3DP’s performance 
on realistic problems, we performed 
several benchmarks on three different 
state-of-the-art architectures. Table 2 
shows some comparisons between the 
3DP, a Sun 4 workstation, and a Silicon 
Graphics Iris workstation. The Sun sys¬ 
tem uses the Sparc architecture and the 
Silicon Graphics uses the MIPS archi¬ 
tecture. These benchmarks are algo¬ 
rithms that are frequently used in robot 
control applications. 9 The common char¬ 


acteristic that the 3DP architecture ex¬ 
ploits is the large number of 3D compu¬ 
tations required to solve these prob¬ 
lems. Therefore, these results are valid 
for any 3D application. 

These benchmarks were obtained 
using identical C++ source code for a 
general-revolute, open-chained, six-de- 
gree-of-freedom robot. The Inverse 
Dynamics benchmark is the computa¬ 
tion required to determine what forces 
must be applied to the robot links in 
order to move at a specified accelera¬ 
tion. The Jacobian calculation gener¬ 
ates a matrix that transforms the joint 
velocities into the endpoint velocity. 
The Kinematics and Dynamics program 
solves for a variety of robot characteris¬ 
tics, and the Forward Kinematics bench¬ 
mark finds the end-effector position giv¬ 
en the joint angles. Uecker et al. 10 showed 
how well the 3DP performs on a com¬ 
plete application in results of an ad¬ 
vanced robot control experiment that 
used the 3DP. 

Table 2 shows that the 3DP is roughly 
three to five times faster than the other 
two architectures. The different per¬ 
centages of 3D vector code for the var¬ 
ious benchmarks account for the varia¬ 
tion in improvement. The Forward 
Kinematics calculation requires a smaller 
percentage of 3D operations than the 
Inverse Dynamics computation. Since 
the 3DP only provides an advantage for 
3D vector operations, Amdahl’s law 2 
will govern the overall speedup for an 
entire application. 

To rationalize the observed perfor¬ 
mance improvement, we can examine 
the equation that motivated the reduced 
instruction-set computing (RISC) ver¬ 
sus complex instruction-set computing 
(CISC) argument: 

Time/Task = (Instructions/Task) x 
(Cycles/Instruction) x (Time/Cycle). 

The objective of processor design is 
obviously to reduce the amount of time 
for the given task. Comparison of the 
3DP architecture to a standard RISC 
architecture identifies the 3DP’s intrin¬ 
sic improvements. The cycles/instruc¬ 
tion is lower because three parallel ex¬ 
ecution units compute vector operations 
faster than a single unit. The time/cycle 
should be equivalent, provided all the 
architectures are compared using the 
same implementation technology. Fi¬ 
nally, the instructions/task is lower be¬ 
cause the 3D instructions are more com- 
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Table 1. 3DP benchmarks. 


Arithmetic Operation 

3DP Performance 

3D add/subtract/multiply 

100 ns/1 cycle 

3D-vector cross product 

400 ns/4 cycles 

3D-vector rotation 

600 ns/6 cycles 

Homogeneous transformation 

700 ns/7 cycles 

Scalar add/subtract/multiply 

100 ns/1 cycle 

Scalar reciprocal approximation 

500 ns/5 cycles 

Vector divided by scalar 

700 ns/7 cycles 


Table 2. Comparison performance benchmarks. 


Operation 

3DP 

(10 MHz) 

Sun4 
(16 MHz) 

SGI 4D70 
(12.5 MHz) 

Inverse Dynamics 

438.8 

1,993.0 (4.54) 

2,491.0 (5.68) 

Jacobian 

339.6 

896.0 (2.64) 

1,080.0 (3.18) 

Kinematics and 
Dynamics 

703.0 

2,828.0 (4.02) 

3,586.0 (5.10) 

Forward Kinematics 

301.4 

783.0 (2.60) 

966.0 (3.21) 


Times in microseconds; 3DP speedup ratios presented in parentheses. 


pact (that is, each instruction specifies a 
complete vector operation), and the 3D 
mode in the compiler eliminates a large 
number of redundant load and store 
operations. Without the 3D mode in the 
compiler, 3D vectors are memory-based 
structures and require constant loading 
and spilling to and from the register file. 

A very large scale integration (VLSI) 
implementation will offer many advan¬ 
tages such as increased clock speed, in¬ 
creased reliability, reduced power con¬ 
sumption, and reduced size. We are 
currently studying a VLSI design and 
have already identified several improve¬ 
ments to the architecture. Incorporat¬ 
ing features that are already designed 
into other processors, such as branch 
squashing and overlapping integer and 
floating-point operations, will improve 
the 3DP’s architectural advantage. De¬ 
tailed optimizations of the execution 
pipeline should also improve perfor¬ 
mance. 

The 3DP real-time 
computer 

The current implementation of the 
3DP architecture is as an attached pro¬ 
cessor that plugs directly into a Sun host 
VMEbus. A device driver enables the 
user to access it through the Unix oper¬ 
ating system. As a device, the 3DP’s 
program memory, data memory, and 
special communication registers are 
mapped into the Unix kernel address 
space. The special communication reg¬ 
isters include a bidirectional FIFO and 
a bidirectional register. The data mem¬ 
ory supports asynchronous data trans¬ 
fers with the host during 3DP program 
execution. Different applications require 
different methods of communication; 
our architecture provides several choic¬ 
es to end users. 

Since a device driver connects the 
3DP to a Unix host, all the Unix facili¬ 
ties — screen editors, windows, file sys¬ 
tems, networking, etc. — are available 
for 3DP program development. Stan¬ 
dard Unix system calls provide access to 
the 3DP. Mathematics and remote pro¬ 
cedure call libraries have been devel¬ 
oped to support program development. 
Figure 9 shows a block diagram of the 
3DP software development environ¬ 
ment. Like the hardware, the 3DP soft¬ 
ware is a second-generation version. 11 

Writing an application for the 3DP 


typically involves the following steps. 
The application is first coded using the 
C++ programming language. A host- 
resident C++ cross-compiler then trans¬ 
lates the C++ source into 3DP assembly 
language, and the 3DP cross-assembler 
produces object code from the assem¬ 
bly source. The object code maybe linked 
with other object code, possibly from 
multiple private or standard libraries, 
to produce an executable 3DP file. The 


loader then downloads the executable 
to the 3DP program memory (via the 
Unix device driver). The loader auto¬ 
matically starts program execution after 
downloading unless requested not to. 

A symbolic debugger assists the de¬ 
bugging of 3DP application programs. 
Instead of writing a debugger from 
scratch, we adapted gdb (the GNU de¬ 
bugger) as a remote symbolic debugger. 
The 3DP remote debugger, db3dp, con- 



Figure 9. The 3DP software development environment. 
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Figure 10. The 3DP software execution environment. 


sists of a language-dependent part (which 
is machine-independent) and a machine- 
dependent part. To minimize 3DP-res- 
ident code and conserve memory, the 
language-dependent code and much of 
the machine-dependent code executes 
on the host. This differs from the origi¬ 
nal gdb in that the 3DP has no “shadow” 
kernel running on it — only the neces¬ 
sary routines like saving and restoring 
the program context reside on the 3DP. 

The 3DP executes its programs au¬ 
tonomously and can therefore operate 
under stringent real-time constraints. 
The Unix host can communicate with 
the 3DP during runtime. However, if 
the 3DP requires data from the host, the 
3DP might not be able to maintain its 
deterministic response time. We envi¬ 
sion data usually passing from the host 
to the 3DP prior to real-time execution. 
The host can sample data from the 3DP’s 
data memory during execution without 
degrading 3DP real-time performance, 
since the hardware design gives the 3DP 
priority access to its data memory. 

An on-board programmable timer and 
dedicated I/O bus are also essential for 
real-time performance. The timer keeps 
track of absolute time for the 3DP, and 
the I/O bus lets the 3DP communicate 
with external sensors and actuators di¬ 
rectly, without accessing the VMEbus. 

Communication mechanisms. Sever¬ 
al hardware features support communi¬ 
cation between the 3DP and the host 


workstation. A pair of FIFOs imple¬ 
ment the command unit (see Figure 1) 
and allow buffered asynchronous mes¬ 
sage passing in both directions. A pair 
of registers, called the command regis¬ 
ters, support nonbuffered message pass¬ 
ing. The 3DP’s data memory is also 
directly accessible from the VMEbus. 
By this path, a host program can moni¬ 
tor variables stored in the data memory 
during runtime without affecting 3DP 
performance. 

The problem of memory contention 
between the host and the 3DP is solved 
by always giving the 3DP higher priori¬ 
ty. The 3DP’s real-time constraints are 
therefore always maintained. The 3DP 
sends a “reservation” signal to the host 
whenever a memory access is approach¬ 
ing. An advanced warning signal is pos¬ 
sible, since the 3DP is a four-stage pipe¬ 
lined processor, and all data memory 
accesses occur during the fourth cycle. 
Because the VME host uses full hand¬ 
shaking on all data transfers, it is forced 
to wait for an available cycle before 
accessing the data memory. 

We used data memory to create three 
full-duplex communication channels that 
support certain dedicated functions. 
Channel 1 is dedicated to the remote- 
procedure-call server (discussed in the 
next section). Channel 2 is used solely 
by the remote symbolic debugger, which 
executes on both the host and the 3DP. 
Channel 3 is reserved for future func¬ 
tionality. The low-level handshaking for 


reliable communication between asyn¬ 
chronous processes is performed with¬ 
in the device driver. Specialized ioctl() 
function calls give users a means for 
accessing these channels. 

Execution environment. Figure 10 
shows the software structure of the 
3DP’s execution environment. All com¬ 
munication between the host and the 
3DP is performed through the Unix 
device driver. Standard Unix system 
calls such as open(), close(), read(), 
write(), and ioctl() allow host programs 
to access the 3DP. 

A remote-procedure-call server exe¬ 
cuting on the host lets the 3DP perform 
Unix system calls. Figure 11 shows the 
communication paths and signaling 
mechanisms between the RPC server, 
user process, device driver, and 3DP. 
The RPC server gives the 3DP com¬ 
plete access to the Unix file system 
and any terminal or peripheral accessi¬ 
ble by the host. For example, the 3DP 
can open(), close(), read(), and write() 
files on the host’s Unix file system. The 
RPC server also supports printf(), 
scanf(), and other important I/O func¬ 
tions. 

The 3DP’s loader plays an important 
role in setting up the real-time execu¬ 
tion environment. The loader opens 
the 3DP in an exclusive mode, so that 
multiple 3DP users logged onto the 
host machine do not collide. Before a 
3DP program is downloaded, the load¬ 
er first clears the program and data 
memories. After the executable code is 
loaded, the loader sets the 3DP into run 
mode, which begins 3DP program exe¬ 
cution. The loader then forks the RPC 
server process, which immediately exe¬ 
cutes a blocking read and waits for an 
RPC request from the 3DP. 

The blocking-read request does not 
complete, or unblock, until there is an 
interrupt from the 3DP. The 3DP inter¬ 
rupts the host whenever it encounters 
an RPC. The interrupt signals the RPC 
server that a service request is pending. 
Before interrupting, the 3DP stores the 
particular RPC’s code number in its 
dedicated communication channel 
(Channel 1). The code number indi¬ 
cates which RPC operation is request¬ 
ed. The RPC server then reads the code 
and performs the appropriate action. 
Any additional data required to per¬ 
form the RPC call is passed through 
Channel 1. 

The loader can optionally fork a user 
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Figure 11. Signaling mechanism and event sequence for an RPC. 


process on the host, which can then 
interact with the 3DP program. For 
example, the user process can be read¬ 
ing shared variables directly from the 
3DP’s data memory while the 3DP is 
continually updating them. This sce¬ 
nario is useful for dynamic simulation 
applications, where the host process 
performs graphics display operations 
and the 3DP continually updates the 
dynamic model. 

Symbolically bound shared variables 
allow the programmer to link parame¬ 
ters from a 3DP program with a host 
program. Binding occurs at compile 
time. The 3DP program is compiled 
first, and a file that includes the data 
memory address of every global vari¬ 
able is generated. The host program 
can then be compiled, and by using 
special routines, the addresses of the 
3DP variables can be linked with the 
host variables. This mechanism pro¬ 
vides an easy method of establishing 
communication between a host pro¬ 
gram and a 3DP program. 


T hrough its novel approach to 
processing 3D vectors in paral¬ 
lel at the instruction-set level, 
the 3DP architecture executes 3D ap¬ 
plications up to five times faster than 
today’s state-of-the-art RISC architec¬ 
tures. We have implemented the 3DP 
architecture as an attached computer 
to a Unix host in a system designed for 
real-time simulation and control appli¬ 
cations. We developed a complete set 
of user-support software tools for this 
implementation, including a C++ com¬ 
piler, RPC library, math library, and 
symbolic debugger. This implementa¬ 
tion verifies the 3DP performance gains 


and meets the system requirements for 
executing programs under real-time 
constraints. 

A VLSI implementation of this ar¬ 
chitecture has already begun. It will 
include several improvements, such as 
branch squashing and overlapped exe¬ 
cution of integer and floating-point op¬ 
erations. Using VLSI will also alleviate 
many previous constraints imposed by 
the functionality from off-the-shelf log¬ 
ic. For example, we can maximize the 
clock speed in the VLSI design, since 
the pipeline stages can be evenly spaced 
(as opposed to constrained by discrete 
chip boundaries). 

Future research will involve expand¬ 
ing this 3D design methodology further 
into the memory hierarchy of a com¬ 
puter system. For example, simulta¬ 
neous vector loads and vector stores 
will reduce the traffic between memory 
and the processor, which is a critical 
bottleneck today. We will also explore 
and program new applications. ■ 
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A distributed system is 
susceptible to a variety 
of security threats 
mounted by intruders. 
We describe a number 
of protocols to 
authenticate users, 
hosts, and processes. 


A S distributed system — a collection of hosts interconnected by a network — 
| poses some intricate security problems. A fundamental concern is au- 
j thentication of local and remote entities in the system. In a distributed 
system, the hosts communicate by sending and receiving messages over the 
network. Various resources (like files and printers) distributed among the hosts 
are shared across the network in the form of network services provided by servers. 
Individual processes (clients) that desire access to resources direct service requests 
to the appropriate servers. Aside from such client-server computing, there are 
many other reasons for having a distributed system. For example, a task can be 
divided into subtasks that are executed concurrently on different hosts. 

A distributed system is susceptible to a variety of threats mounted by intruders 
as well as legitimate users of the system. Indeed, legitimate users are more 
powerful adversaries, since they possess internal state information not usually 
available to an intruder (except after a successful penetration of a host). We 
identify two general types of threats. 

The first type, host compromise, refers to the subversion of individual hosts in a 
system. Various degrees of subversion are possible, ranging from the relatively 
benign case of corrupting process state information to the extreme case of assum¬ 
ing total control of a host. Host compromise threats can be countered by a 
combination of hardware techniques (like processor protection modes) and soft¬ 
ware techniques (like reference monitors). Because these techniques are outside 
our scope, we refer interested readers to Denning 1 for an overview of computer 
systems security. Here, we assume that each host implements a reference monitor 
that can be trusted to properly segregate processes. 

The second type, communication compromise, includes threats associated with 
message communications. We subdivide these into 

• (Tl), eavesdropping of messages transmitted over network links to extract 
information on private conversations; 

• (T2), arbitrary modification, insertion, and deletion of messages transmitted 
over network links to confound a receiver into accepting fabricated messages; 
and 

• (T3), replay of old messages (a combination of (Tl) and (T2)). 
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(Tl) is a passive threat, while (T2) 
and (T3) are active. A passive threat 
does not affect the system being threat¬ 
ened, whereas an active threat does. 
Therefore, passive threats are inherent¬ 
ly undetectable by the system and can 
only be dealt with by using preventive 
measures. Active threats, on the other 
hand, are combated by a combination 
of prevention, detection, and recovery 
techniques. We will not consider threats 
of “traffic analysis” and “denial of ser¬ 
vice” because they are more relevant to 
the general security of a distributed sys¬ 
tem than to our restricted setting of 
authentication. 

Some basic security requirements can 
be formulated. For example, secrecy 
and integrity are two common require¬ 
ments for secure communication. Se¬ 
crecy specifies that a message can be 
read only by its intended recipients, while 
integrity specifies that every message is 
received exactly as it was sent, or a 
discrepancy is detected. 

A strong cryptosystem can provide a 
high level of assurance for secrecy and 
integrity (see “Basic cryptography” side- 
bar). More precisely, an encrypted mes¬ 
sage provides no information regarding 
the original message, hence guarantee¬ 
ing secrecy; and an encrypted message, 
if tampered with, would not decrypt 
into a legal message, hence guarantee¬ 
ing integrity. 

Replay of old messages can be coun¬ 
tered by using nonces or time stamps. 12 
A nonce is information that is guaran¬ 
teed fresh, that is, it has not appeared or 
been used before. Therefore, a reply 
that contains some function of a recent¬ 
ly sent nonce should be considered time¬ 
ly because the reply could have been 
generated only after the nonce was sent. 
Perfect random numbers are good nonce 
candidates; however, their effectiveness 
is dependent upon the randomness that 
is practically achievable. Time stamps 
are values of a local clock. Their use 
requires at least some loose synchroni¬ 
zation of all local clocks, and hence 
their effectiveness is also somewhat re¬ 
stricted. 

What needs 
authentication? 

In simple terms, authentication is iden¬ 
tification plus verification. Identifica¬ 
tion is the process whereby an entity 



Figure 1. Principals in a distributed 
system. 


claims a certain identity, while verifica¬ 
tion is the process whereby that claim is 
checked. Thus, the correctness of an 
authentication relies heavily on the ver¬ 
ification procedure employed. 

The entities in a distributed system 
that can be distinctly identified are col¬ 
lectively referred to as principals. There 
are three main types of authentication 
in a distributed computing system: 

• (Al), message content authentica¬ 
tion — verifying that the content of 
a received message is the same as 
when it was sent; 

• (A2), message origin authentication 
— verifying that the sender of a 
received message is the same one 
recorded in the sender field of a 
message; and 

•(A3), general identity authentica¬ 
tion — verifying that a principal’s 
identity is as claimed. 

(Al) is commonly handled by tagging 
a key-dependent message authentica¬ 
tion code (MAC) onto a message be¬ 
fore it is sent. Message integrity can be 
confirmed upon reception by recom¬ 
puting the MAC and comparing it with 
the one attached. (A2) is a subcase of 
(A3). A successful general identity au¬ 
thentication usually results in a belief 
held by the authenticating principal (the 
verifier) that the authenticated princi¬ 
pal (the claimant) possesses the claimed 
identity. Hence, subsequent claimant 
actions are attributable to the claimed 
identity; for example, general identity 
authentication is needed for both au¬ 
thorization and accounting functions. 
Here, we restrict our attention to gener¬ 
al identity authentication. 

In an environment where both host 
and communication compromises can 
occur, principals must adopt a mutually 
suspicious attitude. Therefore, mutual 
authentication, whereby both commu¬ 


nicating principals verify each other’s 
identity, rather than one-way authenti¬ 
cation, whereby only one principal ver¬ 
ifies the identity of the other principal, 
is usually required. 

In a distributed computing environ¬ 
ment, authentication is carried out us¬ 
ing a protocol involving message ex¬ 
changes. We refer to these protocols as 
authentication protocols. 

Most existing systems use only very 
primitive authentication measures or 
none at all. For example, 

• The prevalent login procedure re¬ 
quires users to enter their passwords in 
response to a system prompt. Users are 
then one-way authenticated by verify¬ 
ing the (possibly transformed) password 
against an internally stored table. How¬ 
ever, no mechanism lets users authen¬ 
ticate a system. This design is accept¬ 
able only when the system is trust¬ 
worthy, or the probability of compro¬ 
mise is low. 

• In a typical client-server interaction, 
the server — on accepting a client’s 
request — has to trust that (1) the resi¬ 
dent host of the client has correctly 
authenticated the client and (2) the iden¬ 
tity supplied in the request actually cor¬ 
responds to the client. Such trust is valid 
only if the system’s hosts are trustwor¬ 
thy and its communication channels are 
secure. 

These measures are seriously inade¬ 
quate because the notion of trust in 
distributed systems is poorly understood. 
A satisfactory formal explication of trust 
has yet to be proposed. Second, the 
proliferation of large-scale distributed 
systems spanning multiple administra¬ 
tive domains has produced extremely 
complex trust relationships. 

In a distributed computing system, 
the entities that require identification 
are hosts, users, and processes. 3 They 
thus constitute the principals involved 
in an authentication, which we describe 
(also see Figure 1). 

Hosts. These are addressable entities 
at the network level. A host is distin¬ 
guished from its underlying supporting 
hardware. For example, host H running 
on workstation A can be moved to work¬ 
station B by performing the bootstrap 
sequence for H on B. A host is usually 
identified by its name (for example, a 
domain name) or its network address 
(for example, an Internet address), 
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Basic cryptography 


A cryptosystem comes with one procedure for encryption 
and another for decryption. A formal description of a crypto¬ 
system includes specifications for message, key, and cipher- 
text spaces, and encryption and decryption functions. 

There are two broad classes of cryptosystems, symmetric 
and asymmetric. 1 In the former, encryption and decryption 
keys are the same and hence must be kept secret. In the lat¬ 
ter, the encryption key differs from the decryption key, and 
the decryption key is kept secret.The encryption key, howev¬ 
er, can be made public. Consequently, it is important that no 
one be able to determine the decryption key from the encryp¬ 
tion key. Symmetric and asymmetric cryptosystems are also 
referred to as shared key and public key cryptosystems, re¬ 
spectively. 

Knowledge of the encryption key allows one to encrypt arbi¬ 
trary messages from the message space, while knowledge of 
the decryption key allows one to recover a message from its 
encrypted form. Thus, the encryption and decryption func¬ 
tions satisfy the following relation: M is the message space, 
K e x K d is the set of encryption/decryption key pairs: 

V m e M: V (k, k~') e K E x K 0 : = m (Cl) 

where [x} y denotes the encryption operation on message x if y 
is an encryption key and the decryption operation on x if y is 
a decryption key. (In the case of a symmetric cryptosystem 
with identical encryption and decryption keys, the operation 
should be clear from the context.) 

Two widely used cryptosystems are the Data Encryption 
Standard (DES), 2 a symmetric system, and RSA, 3 an asym¬ 
metric system. In RSA, encryption-decryption key pairs satis¬ 
fy the following commutative property 4 : 


V/iie M: V (k, /r 1 ) e K E x K 0 : {{m}*-i}*= m (C2) 

hence yielding a signature capability. That is, suppose kand 
/r 1 are P s asymmetric keys, then { m }*-i can be used as P s 
signature on m since it could only have been produced by P, 
the only principal that knows /r 1 . By (C2), Ps signature is 
verifiable by any principal with knowledge of k, Ps public key. 
Note that in (C2), the roles of k and /c 1 are reversed; specifi¬ 
cally, kr' is used as an encryption key while k functions as a 
decryption key. To avoid confusion with the more typical roles 
for kand k~' as exemplified in (Cl), we refer to encryption by 
k -1 as a signing operation. In this article, asymmetric crypto¬ 
systems are assumed to be commutative. 

Since, in practice, symmetric cryptosystems can operate 
much faster than asymmetric ones, asymmetric cryptosys¬ 
tems are often used only for initialization/control functions, 
while symmetric cryptosystems can be used for both initial¬ 
izations and actual data transfer. 


References 


1. G.J. Simmons, “Symmetric and Asymmetric Encryption,” ACM 
Computing Surveys, Vol. 11, No. 4, Dec. 1979, pp. 305-330. 

2. Data Encryption Standard, FIPS Pub. 46, National Bureau of 
Standards, Washington, D.C., Jan. 1977. 

3. R.L. Rivest, A. Shamir, and L. Adleman, “A Method for Obtaining 
Digital Signatures and Public-Key Cryptosystems," Comm. ACM, 
Vol. 21, No. 2, Feb. 1978, pp. 120-126. 

4. W. Diffie and M.E. Heilman, “Privacy and Authentication: An In¬ 
troduction to Cryptography,” Proc. IEEE, Vol. 67, No. 3, Mar. 
1979, pp. 397-427. 


whereas a particular host hardware is 
usually identified by its factory-assigned 
serial number (for example, a worksta¬ 
tion on an Ethernet can be identified by 
the unique address of its Ethernet adapt¬ 
er board). 

Users. These entities are ultimately 
responsible for all system activities. In 
other words, users initiate and are ac¬ 
countable for all system activities. Most 
access-control and accounting functions 
are based on users. (For completeness, 
a special user called root can be postu¬ 
lated, who is accountable for system- 
level activities like process scheduling.) 
Typical users include humans, as well as 
accounts maintained in the user data¬ 
base. Note that users are considered to 
be outside the system boundary. 

Processes. The system creates pro¬ 
cesses within the system boundary to 
represent users. A process requests and 


consumes resources on behalf of its 
unique associated user. Processes fall 
into two classes: client and server. Cli¬ 
ent processes are consumers who ob¬ 
tain services from server processes, who 
are service providers. A particular pro¬ 
cess can act as both a client and a server. 
For example, print servers are usually 
created by (and hence associated with) 
the user root and act as servers for print¬ 
ing requests by other processes. How- 
ever, they act as clients when requesting 
files from file servers. 

Authentication 

exchanges 

We identify the following major types 
of authentication exchanges in a dis¬ 
tributed system. 

Host-host. Host-level activities often 


require cooperation between hosts. For 
example, individual hosts exchange link 
information for updating their internal 
topology maps. In remote bootstrap¬ 
ping, a host, upon reinitialization, must 
identify a trustworthy boot server to 
supply the information (for example, a 
copy of the operating system) required 
for correct initialization. 

User-host. A user gains access to a 
distributed system by logging in a host 
in the system. In an open-access envi¬ 
ronment where hosts are scattered across 
unrestricted areas, a host can be arbi¬ 
trarily compromised, necessitating mu¬ 
tual authentication between the user 
and host. 

Process-process. Two main subclass¬ 
es exist: 

• Peer-process communication. Peer 
processes must be satisfied with each 
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other’s identity before private commu¬ 
nication can begin. 

•Client-server communication. An 
access decision concerning a client’s 
request can be made only when the 
client’s identity is affirmed. A client is 
willing to surrender valuable informa¬ 
tion to a server only after verifying the 
server’s identity. 

As shown later, these two classes of 
communication authentication relate 
closely and can be handled by similar 
protocols. 

From now on, we use authentication 
to refer to general identity authentica¬ 
tion. 

Paradigms of 

authentication 

protocols 

Authentication in distributed systems 
is always carried out with protocols. A 
protocol is a precisely defined sequence 
of communication and computation 
steps. A communication step transfers 
messages from one principal (sender) 
to another (receiver), while a computa¬ 
tion step updates a principal’s internal 
state. Two distinct states can be identi¬ 
fied upon protocol termination, one sig¬ 
nifying successful authentication and the 
other failure. 

Although the goal of any authentica¬ 
tion is to verify the claimed identity of a 
principal, specific success and failure 
states are highly protocol dependent. 
For example, the success of an authen¬ 
tication during the connection estab¬ 
lishment phase of a communication pro¬ 
tocol is usually indicated by the 
distribution of a fresh session key be¬ 
tween two mutually authenticated peer 
processes. On the other hand, in a user 
login authentication, success usually 
results in the creation of a login process 
on behalf of the user. 

We present protocols in the following 
format. A communication step where¬ 
by P sends a message M to Q is repre¬ 
sented as P —> Q: M, whereas a compu¬ 
tation step of P is written as P: . . . , 
where . .” is a specification of the 
computation step. For example, the typ¬ 
ical login protocol between host H and 
user U is given below (/ is a one-way 
function; that is, given y, it is computa¬ 
tionally infeasible to find an x such that 
f(x) = y). 


UH: U 

H —» U: “Please enter password” 

U->H: p 

H : compute y = f(p) 

: retrieve user record ( U , 
f(jpassword v )) from user 
database 

: if y = f(passwordu ) then 
accept; otherwise reject 

We next examine the key ideas that 
underlie authentication protocol design 
by presenting several protocol para¬ 
digms. 

Since authentication protocol para¬ 
digms directly use cryptosystems, their 
basic design principles also follow closely 
the type of cryptosystem used. 

Note that the protocol paradigms il¬ 
lustrate basic design principles only. A 
realistic protocol is necessarily a refine¬ 
ment of these basic paradigms and ad¬ 
dresses weaker environment assump¬ 
tions, stronger postconditions, or both. 
Also, a realistic protocol may use both 
symmetric and asymmetric cryptosys¬ 
tems. 

Protocols based upon symmetric 
cryptosystems. In a symmetric crypto¬ 
system, knowing the shared key lets a 
principal encrypt and decrypt arbitrary 
messages. Without such knowledge, a 
principal cannot obtain the encrypted 
version of a message or decrypt an en¬ 
crypted message. Hence, authentication 
protocols can be designed according to 
the (SYM) principle: If a principal can 
correctly encrypt a message using a key 
that the verifier believes is known only to 
a principal with the claimed identity (out¬ 
side of the verifier), this act constitutes 
sufficient proof of identity. 

Thus (SYM) embodies the proof-by¬ 
knowledge principle for authentication, 
that is, a principal’s knowledge is indi¬ 
rectly demonstrated through encryption 
(see “Approaches to authentication” 
sidebar). Using (SYM), we immediate¬ 
ly obtain the following basic protocol (k 
is a symmetric key shared between P 
and Q). 

P : create m = “I am P.” 

: compute m' = {m} k 

P —> <2: m,m' 

Q : verify [m] k = m' 

: if equal then accept; 
otherwise reject 

Clearly, the (SYM) design principle 
is sound only if the underlying crypto¬ 


system is strong (one cannot find the 
encrypted version of a message without 
knowing the key) and the key is secret 
(it is shared only between the real prin¬ 
cipal and the verifier). Note that this 
protocol performs only one-way authen¬ 
tication. Mutual authentication can be 
achieved by reversing the roles of P 
and Q. 

One major weakness of the protocol 
is its vulnerability to replays. More pre¬ 
cisely, an adversary could masquerade 
as P by recording the message m' and 
later replaying it to Q. As mentioned, 
replay attacks can be countered by us¬ 
ing nonces or time stamps. We modify 
the protocol by adding a challenge-and- 
response step using nonces (n is a nonce). 

P->Q: “I am P.” 

Q^P: n 

P : compute n' = {«}* 

P—*Q- n' 

Q : verify [n} k = n' 

: if equal then accept; 
otherwise reject 

Replay is foiled by the freshness of n. 
Thus, even if an eavesdropper has mon¬ 
itored all previous authentication con¬ 
versations between P and Q, it still could 
not produce the correct n'. (This also 
points out the need for the cryptosys¬ 
tem to withstand known plaintext at¬ 
tack. In other words, the cryptosystem 
must be unbreakable given the knowl¬ 
edge of plaintext-ciphertext pairs.) The 
challenge-and-response step can be re¬ 
peated any number of times until the 
desired level of confidence is reached 
by Q. 

This protocol is impractical as a gen¬ 
eral large-scale solution because each 
principal must store in memory the se¬ 
cret key for every other principal it would 
ever want to authenticate. This presents 
major initialization (the predistribution 
of secret keys) and storage problems. 
Moreover, the compromise of one prin¬ 
cipal can potentially compromise the 
entire system. These problems can be 
significantly reduced by postulating a 
centralized authentication server A that 
shares a secret key k x with every princi¬ 
pal X in the system. 2 The basic authen¬ 
tication protocol then becomes 

P —» Q: “I am P.” 

Q^P. n 

P : compute n = [n) kp 

P^Q : n' 

Q : compute n" = {P, n'} kg 
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Approaches to authentication 

All authentication procedures involve checking known information about a 
claimed identity against information acquired from the claimant during the identi¬ 
ty-verification procedure. Such checking can be based on the following three ap¬ 
proaches.' 

Proof by knowledge. The claimant knows information regarding the claimed 
identity that can only be known or produced by a principal with that identity. For 
example, password knowledge is necessary to most login procedures. A proof by 
knowledge can be conducted by a direct demonstration, like typing in a pass¬ 
word, or by an indirect demonstration, such as correctly computing replies to veri¬ 
fier challenges. Direct demonstration is not preferable from a security viewpoint, 
since a compromised verifier can record the submitted knowledge and later im¬ 
personate the claimant by presenting the recorded knowledge. Indirect demon¬ 
stration can be designed to induce high confidence in the verifier without leaving 
any clue to how the claimant’s replies are computed. For example, Feige, Fiat, 
and Shamir 2 propose a zero-knowledge protocol for proof of identity. This proto¬ 
col allows claimant Cto prove to verifier V/that C knows how to compute replies 
to challenges without revealing the replies. These protocols are provably secure 
(under complexity assumptions). However, additional refinements are needed be¬ 
fore they can be applied in practical systems. 

Proof by possession. The claimant produces an item that can only be pos¬ 
sessed by a principal with the claimed identity, for example, an ID badge. The 
item has to be unforgeable and safely guarded. 

Proof by property. The verifier directly measures certain claimant properties 
with such biometric techniques as fingerprint and retina print. The measured 
property has to be distinguishing, that is, unique among all possible principals. 

Proof by knowledge and possession (and combinations thereof) can be applied 
to all types of authentication needs in a secure distributed system, while proof by 
property is generally limited to the authentication of human users by a host 
equipped with specialized measuring instruments. 
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->A: n" 

A : recover (P, n') from n" by 
decrypting with k.Q 
: compute m = {{n') kp } kQ 

A->Q : m 

Q : verify = m 

: if equal then accept; 
otherwise reject 

Thus Q’s verification step is preceded 
by A’s key translation step. The proto¬ 
col correctness now also rests on A’s 
trustworthiness — that A will properly 
decrypt using P’s key and reencrypt us¬ 
ing Q’s key. The initialization and stor¬ 
age problems are greatly alleviated be¬ 
cause now each principal needs to keep 
only one key. The risk of compromise is 
mostly shifted to A, whose security can 
be guaranteed by various measures, such 
as encrypting stored keys using a master 
key and putting A in a physically secure 
room. 

Protocols based upon asymmetric 
cryptosystems. In an asymmetric crypt¬ 
osystem, each principal P publishes its 
public key k P and keeps secret its pri¬ 
vate key k,}. Thus only P can generate 
{ m ) k -i for any message m by signing it 
using kp l . The signed message {m] k -, can 
be verified by any principal with knowl¬ 
edge of k P (assuming a commutative 
asymmetric cryptosystem). The basic 
design principle is (ASYM): If a princi¬ 
pal can correctly sign a message using 
the private key of the claimed identity, 
this act constitutes sufficient proof of 
identity. 

This (ASYM) principle follows the 
proof-by-knowledge principle for au¬ 
thentication, in that a principal’s knowl¬ 
edge is indirectly demonstrated through 
its signing capability. Using (ASYM), 
we obtain a basic protocol as follows (n 
is a nonce): 

P->Q: “I am P.” 

Q^P: n 

P : compute n' = [n} k -i 

P^Q: «' 

Q : verify n = {n') kp 

: if equal then accept; 
otherwise reject 

This protocol depends on the guaran¬ 
tee that (n) t -i cannot be produced with¬ 
out the knowledge of kp 1 and the cor¬ 
rectness of k P as published by P and 
kept by Q. 

As in protocols that use symmetric 
keys, the initialization and storage prob¬ 


lems can be alleviated by postulating a 
centralized certification authority A that 
maintains a database of all published 
public keys. The protocol can then be 
modified as follows: 

P Q: “lam P.” 

Q^P: n 

P : compute n' = {n} k -, 

P Q'- ri 

Q->A\ “I need P’s public key.” 

A : retrieve c = (P, k P } k - t from 
key database 

A -> Q : P,c 

Q : recover (P, k P ) from c by 
decrypting with k A 


: verify n = { n'} kp 
: if equal then accept; 
-otherwise reject 

Thus public key certificate c repre¬ 
sents a certified statement by A that P’s 
public key is k P . Other information such 
as a specified lifetime and the classifica¬ 
tion of principal P (for mandatory ac¬ 
cess control) can also be included in the 
certificate (such information is omitted 
here). Each principal in the system need 
only keep a copy of the public key k A of 
A. 

In this protocol, A is an example of an 
on-line certification authority, which 
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supports interactive queries and is ac¬ 
tively involved in authentication ex¬ 
changes. A certification authority can 
also operate off line so that a public key 
certificate is issued to each principal 
only once. The certificate is kept by the 
principal and forwarded during an au¬ 
thentication exchange, thus eliminating 
the need to query A interactively. Al¬ 
ternatively, the certificate can be kept 
in an on-line database that is publicly 
accessible. Forgery is impossible, since 
a certificate is signed by the certifica¬ 
tion authority. 

Notion of trust. Correctness of both 
types of protocol paradigms requires 
more than the existence of secure com¬ 
munication channels between principals 
and the appropriate authentication serv¬ 
ers (or certification authorities). In fact, 
such correctness is critically dependent 
on the capability of the servers (author¬ 
ities) to faithfully follow the protocols. 
Each principal bases its judgment on its 
own observations (messages sent and 
received) and its trust of the server’s 
judgment. 

In some sense, less trust is required of 
a certification authority than of an au¬ 
thentication server, because all infor¬ 
mation kept by the authority is public 
(except for its own private key). Fur¬ 
thermore, a certification authority has 
no way of masquerading as a principal 
because a principal’s private key is not 
shared. 

Our formal understanding of trust in 
a distributed system is at best inade¬ 
quate. In particular, a formal under¬ 
standing of authentication would re¬ 
quire both a formal specification of trust 
and a rigorous reasoning method where¬ 
in trust is a basic element. 

Authentic ation 
protocol failures 

Despite the apparent simplicity of the 
basic design principles for authentica¬ 
tion protocols, designing realistic pro¬ 
tocols is notoriously difficult. Several 
published protocols have exhibited sub¬ 
tle security problems. 1A4 

Several reasons for this difficulty ex¬ 
ist. Most realistic cryptosystems satisfy 
algebraic identities additional to those 
in (Cl) and (C2). These extra proper¬ 
ties may generate undesirable effects 
when combined with protocol logic. 


Despite the apparent 
simplicity of basic design 
principles for authentication 
protocols, designing realistic 
protocols is notoriously 
difficult. 


Second, even assuming that the under¬ 
lying cryptosystem is perfect, unexpect¬ 
ed interaction among the protocol steps 
can lead to subtle logical flaws. Third, 
assumptions regarding the environment 
and the capabilities of an adversary are 
not explicitly specified, making it ex¬ 
tremely difficult to determine when a 
protocol is applicable and what final 
states are achieved. 

We illustrate the difficulty by show¬ 
ing an authentication protocol proposed 
by Needham and Schroeder 2 that con¬ 
tains a subtle weakness. 1 Symmetric keys 
k P and k Q are shared between P and A, 
and Q and A, respectively, where A is 
an authentication server. Let k be a 
session key. 

(1) P->A:P, Q, n P 

(2) A -> P: {n P , Q, k, {k, PhJ*, 

(3 ) P->Q: {*, P] kQ 

(4) Q ■-» P : {n Q } k 

(5 ) P^Q: {n Q + l} k 

The message [k, P) k in step 3 can only 
be decrypted, and hence understood, by 
Q. Step 4 reflects Q’s knowledge of k, 
while step 5 assures Q of P’s knowledge 
of k\ hence the authentication hand¬ 
shake is based entirely on knowledge of 
k. The subtle weakness in the protocol 
arises from the fact that the message j/c, 
P} kg sent in step 3 contains no informa¬ 
tion for Q to verify its freshness. (Note 
that only P and A know k to be fresh.) In 
fact, this is the first message sent to Q 
about P’s intention to establish a secure 
connection. An adversary who has com¬ 
promised an old session key k' can im¬ 
personate P by replaying the recorded 
message \k\ P} k in step 3 and subse¬ 
quently executing steps 4 and 5 using k’. 

To avoid protocol failures, formal 
methods may be employed in the design 
and verification of authentication pro¬ 
tocols. A formal design method should 
embody the basic design principles as 


illustrated in the previous section. In 
addition, informal reasoning should be 
formalized within a verification meth¬ 
od. Such informal reasoning would in¬ 
clude statements like “If you believe 
that only you and Bob know k, then you 
should believe any message you receive 
encrypted with k was originally sent by 
Bob,” which must be formally speci¬ 
fied. 

Early attempts at formal verification 
of security protocols mainly follow an 
algebraic approach. 5 Messages ex¬ 
changed in a protocol are viewed as 
terms in an algebra. Various identities 
involving the encryption and decryp¬ 
tion operators (for example, (Cl) and 
(C2)) are taken to be term-rewriting 
rules. A protocol is secure if it is impos¬ 
sible to derive certain terms (for exam¬ 
ple, the term containing the key) from 
the terms obtainable by an adversary. 
The algebraic approach is limited, since 
it has been used mainly to deal with one 
aspect of security, namely secrecy. Re¬ 
cently, logical approaches have been 
proposed to study authentication pro¬ 
tocols. 4 Most of these logics adopt a 
modal basis, with belief and knowledge 
as central notions. The logical approach¬ 
es appear to be more general than the 
algebraic ones, but they lack the rigor¬ 
ous foundation of more well-estab¬ 
lished systems like first-order and tem¬ 
poral logics. A satisfactory semantic 
model for these systems has not been 
developed. Much research is needed to 
obtain sound design methods and to 
formally understand authentication is- 


Authentication 

framework 

We synthesize basic concepts into an 
authentication framework that can be 
incorporated into the design of secure 
distributed systems. We identify five 
aspects of secure distributed system 
design and the associated authentica¬ 
tion needs. (This section is not exhaus¬ 
tive in scope because other issues may 
have to be addressed in an actual dis¬ 
tributed system security framework. 
Also, the presented protocols are not 
meant to be definitive or optimal.) The 
five aspects are 

• Host initializations. All process ex¬ 
ecutions take place inside hosts. Some 
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Figure 2. Distributed system configuration. 


hosts (like workstations) also act as sys¬ 
tem-entry points by allowing user log¬ 
ins. The overall security of a distributed 
system is highly dependent on the secu¬ 
rity of each host. However, in an open 
network environment, not all hosts can 
be physically protected. Thus resistance 
to compromise must be built into a host’s 
software to ensure secure operation. 
This suggests the importance of host 
software integrity. Loading a host that 
employs remote initialization with the 
correct host software is necessary to its 
proper functioning. In fact, one way to 
compromise a public host is to reboot 
the host with incorrect initialization in¬ 
formation. Authentication can be used 
to implement secure bootstrapping. 

• User logins. User identity is estab¬ 
lished at login, and all subsequent user 
activities are attributed to this identity. 
All access-control decisions and account¬ 
ing functions are based on this identity. 
Correct user identification is thus cru¬ 
cial to the functioning of a secure sys¬ 
tem. Since any host in an open environ¬ 
ment is susceptible to compromise, a 
user should not engage in any activity 
with a host without first ascertaining 
the host’s identity. A mutual user-host 
authentication can achieve the required 
guarantees. 

• Peer communications. Distributed 
systems can distribute a task over mul¬ 
tiple hosts to achieve a higher through¬ 
put or more balanced utilization than 
centralized systems. Correctness of such 
a distributed task depends on whether 
peer processes participating in the task 
can correctly identify each other. Au¬ 
thentication can identify friend or foe. 

• Client-server interactions. The cli¬ 
ent-server model provides an attractive 
paradigm for constructing distributed 
systems. Servers are willing to provide 
service only to authorized clients, while 
clients are interested in dealing only 
with legitimate servers. Authentication 
can be used to verify a potential con¬ 
sumer-supplier relationship. 

• Interdomain communication. Most 
distributed systems are not centrally 
owned or administered; for example, a 
campus-wide distributed system often 
interconnects individually administered 
departmental subsystems. Identifying 
principals across subsystems requires 
additional authentication mechanisms. 

In the kind of malicious environments 
postulated in our threats model, some 
basic assumptions about the system must 


be satisfied to achieve a reasonable lev¬ 
el of security. We offer a set of assump¬ 
tions (for other possible assumptions, 
see Abadi et al. 6 and Linn 3 ). Figure 2 
also depicts these assumptions. 

• Each host hardware W has a unique 
built-in immutable identity id w and con¬ 
tains a tamperproof cryptographic fa¬ 
cility that encapsulates the public key 
k w and the private key k^ of W. The 
cryptographic facility can communicate 
with the host reference monitor via a 
secure channel. Each host that supports 
user logins also has a smart card reader 
that communicates with the host refer¬ 
ence monitor via a secure channel. Last¬ 
ly, the host reference monitor has a 
secure channel to the network inter¬ 
face. 


• Each legitimate user U is issued a 
smart card C that has a unique built-in 
immutable identity id c . Each smart card 
C performs encryption and decryption, 
and encapsulates its private key kc, the 
public key for the certification authori¬ 
ty k A , and a pin number Pin c for its 
legitimate holder. (The pin number is 
assigned by a card-issuing procedure.) 
The channel between the smart card 
and reader is secure. Each smart card 
has its own display, keypad, and clock. 

• A physically secure centralized 
bootstrap server B maintains a data¬ 
base of host information. More precise¬ 
ly, for each host H, it keeps a record 
(id H , k H , k u \ id w , k w , k^') specifying the 
unique hardware W that can be initial¬ 
ized as H. All database records can be 
encrypted under a secret master key for 
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(1) W —> all: 

: “boot,” id w , [n w , id w ] k 

(2) B 

: retrieve record ( id H , k H , k H \ id w , k w , k„') 


for W from database 


: recover n w from [n w , id w } k 


by decrypting with krf 


: generate a random key k 


: compute m = { n w , k A , k B , k} k 

(3) B ->W: m 

(4) W 

: recover (n w , k A , k B , k) from m 


by decrypting with k n ! 

(5) W-> B 

{n w , “ready”}^ 

(6) B -> W 

[n w , n B , id„, [kj\ k , 05}* 

(7 )W-> B 


(8 ) B ->W 

| id„, id w , k„, T) kj; 

(9) H 

validate certificate [id H , id w , k H , T} k , 


by encrypting with k B 


Figures 3. Secure bootstrap protocol. 


added security. B has a pub¬ 
lic key k B and a private key 

k~ B '. 

• A physically secure cen¬ 
tralized certification author¬ 
ity A maintains a database 
on all principals. More pre¬ 
cisely, for each 
keeps a record (U, id c , k c ), 
binding U to its smart card C. 

For each host H, A keeps a 
record (id H , id w ), specifying 
the hardware W that H can 
run on. Also, for each server 
S, A keeps a record of its 
public key certificate (5, k s ). 

The certification authority A 
has a public key k A and a 
private key k A . 

Each assumption is achiev¬ 
able with current technolo¬ 
gy. In particular, the technol¬ 
ogy of a battery-powered 
credit-card-sized smart card 
with a built-in LCD and key¬ 
pad that can perform special¬ 
ized computations has steadi¬ 
ly progressed. Also, many vendors 
include specialized cryptographic facil¬ 
ities and smart card readers for hosts as 
options. The use of a smart card or 
other forms of computational aid is es¬ 
sential to realizing mutual authentica¬ 
tion between a host and a user. Unaided 
human users simply cannot carry out 
the intensive computations required by 
an authentication protocol. 

We assume the bootstrap server and 
certification authority are centralized. 
Decentralized servers/authorities can be 
supported by adding authentication be¬ 
tween them, as we discuss later. Such 
authentication can be carried out in a 
hierarchical manner as suggested in the 
protocol standard CCITT X.509. 

Although we have a certification au¬ 
thority in our framework, we chose to 
omit an authentication server because 
we deemed the trust level needed in a 
certification authority (which distrib¬ 
utes public key certificates) to be less 
than that of an authentication server. 

Secure bootstrapping. The following 
protocol is initiated when host hard¬ 
ware attempts a remote initialization. 
This could occur after a voluntary shut¬ 
down, a system crash, or a malicious 
attack by an adversary who attempts to 
penetrate the host. The secure boot¬ 
strap protocol allows a reinitialized host 


to attain a “safe” state prior to resuming 
normal operation. In particular, a cor¬ 
rectly loaded reference monitor is ready 
to assume control of the host in this 
state. 

Suppose that the hosts and the boot¬ 
strap server B are on the same broad¬ 
cast network, allowing the message in 
step 1 of Figure 3 to be received by B. 
In that protocol, n w and n B are nonces, 
A: is a session key, OS is a copy of the 
operating system, and T is a time 
stamp. 

In step 1, W announces its intention 
to reboot by broadcasting a boot re¬ 
quest. Only B (which has knowledge of 
k w l ) can recover the nonce n w . In step 2, 
B generates a fresh key k to be used for 
loading OS. In step 4, W ascertains that 
m is not a replay by checking the com¬ 
ponent n w , since only B could have com¬ 
posed message m. Thus k A , k B , and k in 
m can be safely taken to be the public 
key of certification authority A, the 
public key of B, and the session key to 
be used for loading OS. At this point, B 
has been authenticated by W. 

When the message “ready” encrypt¬ 
ed with k is received in step 5, B is 
certain that the original boot request 
actually came from W, since only W can 
decrypt m to retrieve k. Hence, B and W 
have mutually authenticated each 
other. 


Step 6 is the actual loading 
of OS and the transferring of 
host H’ s private key k„. OS 
includes its checksum, which 
should be recomputed by W 
to detect any OS tampering 
in transit. W acknowledges 
receipt of k,, [ and OS by re¬ 
turning the nonce n B signed 
with kfj'. B verifies that the 
correct n B is returned. Then 
in step 8, a license signed by 
B affirming the binding of 
host id H with public key k H 
and hardware id w is sent to 
W. After receiving the license, 
W officially “becomes” H, 
which retains this license as 
proof of successful bootstrap¬ 
ping and of its own identity. 
The time stamp field T with¬ 
in the license denotes its ex¬ 
piration date. 

If its secrecy is not required, 
OS can be transferred unen¬ 
crypted. However, the check¬ 
sum of OS must be sent in 
encrypted form. 

User-host authentication. This func¬ 
tion occurs when user U walks up to 
host H and attempts to log in. The au¬ 
thentication requires smart card C. A 
successful authentication guarantees 
host H that U is the legitimate holder of 
C and guarantees user U that H is a 
“safe” host to use. The host is safe if it 
holds a valid license (which may have 
been obtained through secure bootstrap¬ 
ping) and possesses knowledge of the 
private key k„. 

In most systems, the end result of a 
successful user authentication is the cre¬ 
ation of a login process by the host’s 
reference monitor on the user’s behalf. 
The login process is a proxy for the user, 
and all requests generated by this pro¬ 
cess are taken as if they are directly 
made by the user. However, a remote 
host/server has no way of confirming 
such proxy status, except to trust the 
authentication capability and integrity 
of the local host. Such trust is unaccept¬ 
able in a potentially malicious environ¬ 
ment because a compromised host can 
simply claim the existence of user login 
processes to obtain unauthorized ser¬ 
vices. 

This trust requirement can be al¬ 
leviated if a user explicitly delegates 
authority to the login host. 3 6 The del¬ 
egation is carried out by having the 
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'• (1) C -» H: 

id c , n c 

(2) H -* A: 

id c , { id„, id w , k H , T\ k . t 

(3) A 

check time stamp of certificate 


if time stamp expired, abort 

(4) A -* H: 

{id H , id w , k,„ T] k -x, {U, id c , k c } k . 

(5) H : 

generate new delegation key pair 


(k d , k d ') 

(6) H -* C: 

[id H , id w , k H , T} k - U \U, k d , n c } k - 

(7) C -> U: 

id m id w 

(8) U : 

verify if id H lid w is the desired host 


if not, abort 

(9) U -» C: 

Pin 

(10) C : 

verify Pin = Pin c 


if not equal, abort 

(11) C -> H: 

[U, id„, k d , T c } k ., 

(12) H : 

verify correct delegation by decrypting 


the login certificate (t/, id H , k d , T c } k -, 


with k c 


Figure 4. User-host authentication protocol. 


user’s smart card sign a login 
certificate to the login host 
upon the successful termi¬ 
nation of a user-host au¬ 
thentication protocol. The 
login certificate asserts the 
host’s proxy status with re¬ 
spect to the user and can be 
presented by the host in 
future authentication ex¬ 
changes. 

Because forgery can occur, 
the possession of a logii 
tificate should not be taken 
as sufficient proof of delega¬ 
tion. The host also must dem¬ 
onstrate the knowledge of a 
private delegation key k j 1 
whose public component k d 
is named in the certificate. 

Also, to reduce the potential 
impact of a host compromise, 
the login certificate is given 
only a finite lifetime by in¬ 
cluding an expiration 
stamp. 

We present such a user- 
host authentication protocol 
in Figure 4. We assume that the host 
holds a valid license {id H , id w , k H , T} k , 
as would be the case if the host has 
executed the secure bootstrap protocol. 
In the figure, n c is a nonce, k d is the 
public delegation key whose private 
counterpart k d ' is kept secret by the 
host, and T c is a time stamp denoting 
the expiration date of the login certifi¬ 
cate. 

A user inserts his/her smart card into 
the host’s card reader. The card’s iden¬ 
tity id c and a nonce n, are sent through 
the card reader to the host in step 1. In 
step 2, H requests user information as¬ 
sociated with id c from certification au¬ 
thority A. Since the license held by H 
was signed by B and hence is not deci¬ 
pherable by C, a key translation is re¬ 
quested by H in the same step. (Note 
that these licenses can be cached by H 
and need not be requested for every 
user authentication.) After receiving a 
reply from A in step 4, H knows both the 
legitimate holder U of the card C and 
the public key k c associated with the 
smart card. Knowledge of U can be used 
to enforce the local discretionary con¬ 
trol to provide service (or not), while k c 
is needed to verify the authenticity of C. 
In step 5, H generates a new delegation 
key pair (k d , k d ').H keeps k d ' private, to 
be used as proof of a successful delega¬ 
tion from U to //. 


In step 6, H returns the nonce n c with 
the public delegation key k d and a copy 
of its license to C. In step 7, C retrieves 
(id H , id w ), the identity of //, from the 
license by decrypting it with k A . A check 
ensures that the time stamp in the li¬ 
cense has not expired. The identity ( id H , 
id w ) is then displayed on the card’s own 
screen. To proceed, the user enters the 
assigned pin number on the card’s key¬ 
pad. In step 10, the pin number is com¬ 
pared with the one stored in the card. If 
they are equal, C signs a login certifi¬ 
cate binding the user U with the host id H 
and the public delegation key k d . This is 
sent to H in step 11. The host (and 
others) can verify the validity of the 
login certificate using k c , the card’s pub¬ 
lic key. 

When user U logs out, the host erases 
its copy of the private delegation key k 
to void the delegation from U. If H is 
compromised after the delegation, the 
effect of the login certificate is limited 
by its lifetime, T c . 

Peer-peer authentication. This type 
of mutual authentication and crypto¬ 
graphic parameters negotiation is per¬ 
formed in the connection-establishment 
phase of a secure connection-oriented 
protocol. 

The protocol in Figure 5 mutually 
authenticates peers P and Q, and estab¬ 


lishes a new session key for 
their future communication 
(n P and n Q are nonces, while 
k is a fresh session key). 

In step 1, P informs A of its 
intention to establish a se¬ 
cure connection with Q. In 
step 2, A returns to P a copy 
of Q’s public key certificate. 
In step 3, P informs Q of its 
desire to communicate, and 
sends a nonce n P . In step 4, Q 
asks A for P’s public key cer¬ 
tificate and requests a ses¬ 
sion key at the same time. In 
order for Q to subsequently 
prove to P that the session 
key k is actually from A (not 
Q’s own creation), A sends a 
signed statement containing 
the key k, n P , and Q’s name. 
This basically says that k is a 
key generated by A on behalf 
of Q’s request identified by 
n P . The binding of k and n P 
assures P that k is fresh. In 
step 6, A’s signed copy of 
( n P , k, Q) is relayed to P to¬ 
gether with a nonce n Q generated by Q. 
P’s knowledge of the new session key k 
is indicated to Q by the receipt of n Q in 
step 7. 

Client-server authentication. Since 
both clients and servers are implement¬ 
ed as processes, the basic protocol for 
peer-peer authentication can be applied 
here as well. However, several issues 
peculiar to client-server interactions 
need to be addressed. 

In a general-purpose distributed com¬ 
puting environment, new services (hence 
servers) are made available dynamical¬ 
ly. Thus, instead of informing clients of 
every service available, most implemen- 


(1) p -» x 

P.Q 

(2) A -> P 

(a k Q } k . 

(3) P -» Q 

K P) kQ 

(4) Q -» A 

Q, P, tn,)* x 

(5) A -» Q 

\P, k P ) k ,, 


{{ n P , k, Q} k ,,} kg 

(6) Q -> P 

: [{n F , k, Q) k -x, n Q } kp 

(7) P Q 

: \n Q } k 


Figure 5. Peer-peer authentication 
protocol. 
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U^H 

U 

H —> Kerberos 

U, TGS 

Kerberos 

retrieve k u and k TGS from database 
generate a new session key k 
create ticket-granting ticket 
tick TGS = [U, TGS , k, T, L}„ tcs 

Kerberos —» H 

{TGS, k, T, L, tick TGS } kv 

//-> U 

“Password?” 

£/— 

passwd 

H 

compute £ = f (jpasswd) 
recover k, tick TGS by decrypting 
[TGS, k, T, L, tick TGS } ku with £ 
if decryption fails, abort login 
otherwise retain tick TGS and k 
erase passwd from memory 


Figure 6. Kerberos credential-initialization protocol. 


tations use a service broker 
to keep track of and direct 
clients to appropriate provid¬ 
ers. A client first contacts the 
service broker by using a pur¬ 
chase protocol that performs 
the necessary mutual authen¬ 
tication prior to the granting 
of a ticket. The client later 
uses the ticket to redeem ser¬ 
vices from the actual server 
by using a redemption pro¬ 
tocol. 

Authentication performed 
by the purchase protocol pro¬ 
ceeds the same way as the 
protocol for peer-to-peer 
authentication, while in the 
redemption protocol authen¬ 
tication is based upon pos¬ 
session of a ticket and knowl¬ 
edge of some information 
recorded in the ticket. Such a ticket 
contains the names of the client and 
server, a key, and a time stamp to indi¬ 
cate lifetime (similar to a login certifi¬ 
cate). A ticket can be used only be¬ 
tween the specified client and server. A 
prime example of this approach is the 
Kerberos authentication system, which 
we later discuss. 

Another special issue of client-server 
authentication is proxy authentication. 7 
To satisfy a client’s request, a server 
often needs to access other servers on 
behalf of the client. For example, a da¬ 
tabase server, upon accepting a query 
from a client, may need to access the file 
server to retrieve certain information 
on the client’s behalf. A straightfor¬ 
ward solution would require the file 
server to directly authenticate the cli¬ 
ent. However, this may not be feasible. 
In a long chain of service requests, the 
client may not be aware of a request 
made by a server in the chain and hence 
may not be in a position to perform the 
required authentication. An alternative 
is to extend the concept of delegation 
previously used in user-host authenti¬ 
cation. 7 A client can forward a signed 
delegation certificate affirming the del¬ 
egation of its rights to a server along 
with its service request. The server is 
allowed to delegate to another server 
by signing its own delegation certificate 
as well as by relaying the client’s certif¬ 
icate. In general, for a service request 
involving a sequence of servers, delega¬ 
tion can be propagated to the final serv¬ 
er through intermediate ones, forming 
a delegation chain. 


Various refinements can extend the 
scheme. A form of restricted delegation 
can be carried out by explicitly specify¬ 
ing a set of rights and/or objects in a 
delegation certificate. 

Interdomain authentication. We have 
assumed a centralized certification au¬ 
thority trusted by all principals. How¬ 
ever, a realistic distributed system is 
often composed of subsystems indepen¬ 
dently administered by different author¬ 
ities. We use the term domain to refer to 
such a subsystem. Each domain D main¬ 
tains its own certification authority A D 
that has jurisdiction over all principals 
within the domain. Intradomain authen¬ 
tication refers to an exchange between 
two principals belonging to the same 
domain, whereas interdomain authenti¬ 
cation refers to an exchange that in¬ 
volves two principals belonging to dif¬ 
ferent domains. 

Using the previously described pro¬ 
tocols, A d is sufficient for all intrado¬ 
main authentications for each domain 
D. However, a certification authority 
has no way of verifying a request from a 
remote principal, even if the request is 
certified by a remote certification au¬ 
thority. Hence, additional mechanisms 
are required for interdomain authenti¬ 
cation. 

To allow this type of authentication, 
two issues need to be addressed: nam¬ 
ing and trust. Naming ensures that prin¬ 
cipals are uniquely identifiable across 
domains, so that each authentication 
request can be attributed to a unique 
principal. A global naming system span¬ 


ning all domains can be used 
to provide globally unique 
names to principals. A good 
example of this is the Do¬ 
main Name System used in 
Internet. 

Trust refers to the willing¬ 
ness of a local certification 
authority to accept a certifi¬ 
cation made by a remote au¬ 
thority regarding a remote 
principal. Such trust relation¬ 
ships must be explicitly es¬ 
tablished between domains, 
which can be achieved by 

• sharing an interdomain key 
between certification au¬ 
thorities that are willing to 
trust each other, 

• installing the public keys of 
all trusted remote authori¬ 
ties in a local certification authori¬ 
ty’s database, and 

• introducing an interdomain author¬ 
ity for authenticating domain-level 
authorities. 

A hierarchical organization corre¬ 
sponding to that of the naming system 
can generally be imposed on the certifi¬ 
cation authorities. In this case, an au¬ 
thentication exchange between two 
principals P and Q involves multiple 
certification authorities on a path in 
the hierarchical organization between 
P and Q. s The path is referred to as a 
certification path. 

Case studies 

We study two authentication servic¬ 
es: Kerberos and SPX. Both address 
client-server authentication needs. Their 
services are generally available to an 
application program through a program¬ 
ming interface. While Kerberos uses a 
symmetric cryptosystem, SPX uses an 
asymmetric cryptosystem as well. 

Kerberos. This system was designed 
for Project Athena at the Massachu¬ 
setts Institute of Technology. 9 The 
project goal is to create an educational 
computing environment based on high- 
performance workstations, high-speed 
networking, and servers of various types. 
Researchers envisioned a large-scale 
(10,000 workstations to 1,000 servers) 
open-network computing environment 
in which individual workstations can be 
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privately owned and operated. There¬ 
fore, a workstation cannot be trusted to 
identify its users correctly to network 
services. Kerberos is not a complete 
authentication framework required for 
secure distributed computing in gener¬ 
al; it only addresses issues of client- 
server interactions. 

We limit our discussion to the Ker¬ 
beros authentication protocols and omit 
various administrative issues. 

The design is based on using a sym¬ 
metric cryptosystem with trusted third- 
party authentication servers. It is a re¬ 
finement of ideas presented in Needham 
and Schroeder. 2 The basic components 
include Kerberos authentication and 
ticket-granting servers (TGSs). A data¬ 
base contains information on each prin¬ 
cipal. It stores a copy of each principal’s 
key that is shared with Kerberos. For a 
user principal U, its shared key k v is 
computed from its password password 
specifically, k v = f (password,]) for some 
one-way function /. Kerberos servers 
and TGSs read the database in the course 
of authentication. 

Kerberos uses two main protocols. 
The credential-initialization protocol 
authenticates user logins and installs 
initial tickets at the login host. A client 
uses the client-server authentication 
protocol to request services from a 
server. 

The credential-initialization protocol 
uses Kerberos servers. Let U be a user 
who attempts to log into host H, and / 
be the one-way function for computing 
k v from IP s password. The protocol is 
specified in Figure 6 (here, Kerberos 
refers to the server): 

If passwd is not the valid password of 
U, l would not be identical to k v , and 
decryption in the last step would fail. 
(In practice,/may not be one-to-one. It 
suffices to require that given two dis¬ 
tinct elements x and y, the probability 
of f(x) being equal to f(y) is negligible.) 
Upon successful authentication, the host 
obtains a new session key k and a copy 
of the ticket-granting ticket 

tick TGS = (U, TGS, k, T, L} kms , 

where T is a time stamp and L is the 
ticket’s lifetime. The ticket-granting tick¬ 
et is used to request server tickets from 
a TGS; note that tick TGS is encrypted 
with k TGS , the shared key between TGS 
and Kerberos. 

Because a ticket is susceptible to in¬ 
terception or copying, it does not con¬ 


(1) C —» TGS: 

(2) TGS : 


(3) TGS -> C: 

(4) C : 

(5 )C-»5 : 
(6)5 : 


S, tick TGS , [C, T x } k 

recover k from tick ras by decrypting with k Tas 

recover 7, from [C, T,\ k by decrypting with k 

check timeliness of 7) with respect to local clock 

create server ticket tick s = {C, 5, k', T, L'} ks 

(5, k', V, L\ tick s ) k 

recover k', tick s by decrypting with k 

tick s . 1C T 2 } k . 

recover k' from tick s by decrypting with k s 
recover T 2 from {C, 7 2 )*. by decrypting with k' 
check timeliness of T 2 with respect to local clock 


(7) S-+C : {7 2 + l}*; 


Figure 7. Kerberos client-server authentication protocol. 


stitute sufficient proof of identity. 
Therefore, a principal presenting a tick¬ 
et must also demonstrate knowledge of 
the session key k named in the ticket. 
An authenticator (to be described) pro¬ 
vides the demonstration. Figure 7 shows 
the protocol for client C to request 
network service from server 5(7, and 
T 2 are time stamps). 

In step 1, client C presents its ticket¬ 
granting ticket tick TGS to TGS to re¬ 
quest a ticket for server 5. (Note that 
each client process associates with the 
unique user who created the process. It 
inherits the user ID and the ticket¬ 
granting ticket issued to the user dur¬ 
ing login.) C’s knowledge of k is dem¬ 
onstrated using the authenticator 
[C,T,\ k . In step 2, TGS decrypts tick TGS , 
recovers k, and uses it to verify the 
authenticator. If both step 2 decryp¬ 
tions are successful and 7, is timely, 
TGS creates a ticket tick s for server 5 
and returns it to C. Holding tick s , C 
repeats the authentication sequence 
with 5. Thus, in step 5, C presents 5 
with tick s and a new authenticator. In 
step 6, S performs verifications similar 
to those performed by TGS in step 2. 
Finally, step 7 assures C of the server’s 
identity. Note that this protocol requires 
“loosely synchronized” local clocks for 
the verification of time stamps. 

Kerberos can also be used for au¬ 
thentication across administrative or 
organizational domains. Each domain 
is called a realm. Each user belongs to 
a realm identified by a field in the us¬ 
er’s ID. Services registered in a realm 
will accept only, tickets issued by an 


authentication server for that realm. 

An interrealm key supports cross¬ 
realm authentication. The TGS of one 
realm can be registered as a principal in 
another by using the shared interrealm 
key. A user can thus obtain a ticket¬ 
granting ticket for contacting a remote 
TGS from its local TGS. When the tick¬ 
et-granting ticket is presented to the 
remote TGS, it can be decrypted by the 
remote TGS, which uses the appropri¬ 
ate interrealm key to ascertain that the 
ticket was issued by the user’s local 
TGS. An authentication path spanning 
multiple intermediate realms is possi¬ 
ble. 

Kerberos is an evolving system on its 
fifth version. Bellovin and Merritt 10 dis¬ 
cuss limitations of previous versions, 
some of which have been remedied. 

SPX. This authentication service is 
also intended for open-network envi¬ 
ronments. 11 SPX is a major component 
of the Digital Distributed System Secu¬ 
rity Architecture 8 and its functionalities 
resemble those'of Kerberos. It has cre¬ 
dential-initialization and client-server 
authentication protocols. In addition, it 
has an enrollment protocol that regis¬ 
ters new principals. We focus on the 
first two protocols and omit the last, 
along with most other administrative 
issues. 

SPX has a Login Enrollment Agent 
Facility (LEAF) and a Certificate Dis¬ 
tribution Center (CDC) that corre¬ 
sponds to Kerberos servers and TGSs. 
LEAF, similar to a Kerberos server, is 
used in the credential-initialization pro- 
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(1) U^H 

U, passwd 

(2) H -4 LEAF 

U, [T, n, ^(passwd)} kLEfs 

(3) LEAF -4 CDC: U 

(4) CDC -4 LEAF: {{kj}^^, ^(password „)}*, {k} kiiM . 

(5) LEAF 

recover k by decrypting with k]} EAe 
recover {ku x } h2(pa! , snordu) and h^passwordy) by 
decrypting with k 
verify hjpasswd) = h ^password,) 
if not equal, abort 

(6) LEAF -4 H 


(7 )H 

recover k[}' by decrypting first with n and then with 
h 2 (passwd) 

generate (RSA) delegation key pair {k d , k d ') 
create ticket tick,, = {L, U, k d \ k i 

(8) //-»CDC 

U 

(9) CDC -4 H 

[A, k A } k j 


Figure 8. STX credential-initialization protocol. 


tocol. CDC is an on-line depository con¬ 
sisting of public key certificates (for 
principals and certification authorities) 
and the encrypted private keys of prin¬ 
cipals. Note that CDC need not be trust¬ 
worthy because everything stored in it 
is encrypted and can be verified inde¬ 
pendently by principals. 

SPX also contains hierarchically or¬ 
ganized certification authorities (CAs), 
which operate off line and are selective¬ 
ly trusted by principals. Their function 
is to issue public key certificates (bind¬ 
ing names and public keys of princi¬ 
pals). Global trust is not needed in SPX. 
Each CA typically has jurisdiction over 
just one subset of all principals, while 
each principal P trusts only a subset of 
all CAs, referred to as the trusted au¬ 
thorities of P. System scalability is greatly 
enhanced by the absence of global trust 
and on-line trusted components. 

The credential-initialization protocol 
is performed when a user logs in (see 
Figure 8). It installs a ticket and a set of 
trusted-authority certificates for the user 
upon successful login. In the protocol, 
U is a user who attempts to log in to host 
//;passwd is the password entered by U\ 
T is a time stamp; L is the lifetime of a 
ticket; n is a nonce; h , and h 2 are publicly 
known one-way functions; k is a (DES) 
session key; k v , /c LEAF , k A are respective¬ 
ly the public keys of U, the LEAF serv¬ 
er, and a trusted authority A of U; and 


k,j l and k FEAF are respectively the pri¬ 
vate keys of U and LEAF. 

In step 1, user U enters its ID and 
password. In step 2, H applies the one¬ 
way function h, to the password U en¬ 
tered and sends the result, along with a 
time stamp T and a nonce n, in a mes¬ 
sage to LEAF. Upon receiving the mes¬ 
sage from H, LEAF forwards a request 
to CDC for U' s private key. This key is 
stored as a record 
h t (passwordu)) in CDC. Note that a 
compromise of CDC would not reveal 
these private keys. In step 4, CDC sends 
the requested private-key record to 
LEAF using a temporary session key k. 
In step 5, LEAF recovers both 
w„) and h { (password L ) from 
CDC’s reply. LEAF then verifies 
passwd by checking h^asswd) against 
h , {password u ) .Iftheyarenotequal,the 
login session is aborted and the abor¬ 
tion logged. Because h^asswordv) is 
not revealed to any principal except 
LEAF, password-guessing attacks would 
require contacting LEAF for each guess 
or compromising LEAF’S private key. 

Having determined the password to 
be valid, LEAF sends the first part of 
the private-key record encrypted by n 
to H in step 6. (The nonce n sent in step 
2 is used as a symmetric key for encryp¬ 
tion.) In step 7, H recovers k by de¬ 
crypting the reply from LEAF first with 
n and then with h 2 {passwd '). H then gen¬ 


erates a pair of delegation keys and 
creates a ticket tick v . In step 8, H re¬ 
quests the public key certificate for a 
trusted authority of U from CDC. CDC 
replies with the certificate in step 9. In 
fact, multiple certificates can be returned 
in step 9 if U trusts more than one CA. 
These trusted authorities’ certificates 
were previously deposited in the CDC 
by U using the enrollment protocol. 

The authentication-exchange proto¬ 
col between a client C and a server 5 
follows. To simplify the protocol speci¬ 
fication so that a single public key cer¬ 
tificate is sent in step 2 and in step 5, we 
made the following assumption: Let C’s 
public key certificate be signed by A c 
where A c denotes a trusted authority of 
5. Similarly, let 5’s public key certificate 
be signed by A s where A 5 denotes a 
trusted authority of C. Below, T is a 
time stamp, and k is a (DES) session 
key: 


(1) C —» CDC: 5 

(2) CDC -4 C : {5, k s }„^ 

(3) C —> 5 : 7’, {k) k *tick c , \k d \ 

(4) 5 -4 CDC : C 

(5) CDC -4 5: [C, k c } kA 

(6) 5 : validate tick c by 


encrypting with k c 
(7) 5 —> C : (7’+ 1) 4 


In step 1, C requests 5’s public key 
certificate from CDC. In step 2, CDC 
returns the requested certificate. C can 
verify the public key certificate by de¬ 
crypting it with k As , which is the public 
key of A s obtained by C when it execut¬ 
ed the credential-initialization proto¬ 
col. In step 3, tick c and the private del¬ 
egation key k d ' generated in step 7 of 
the credential-initialization protocol, as 
well as a new session key k, are sent to 
5. Only 5 can recover k from and 
subsequently decrypt \k- d l } k to recover 
k d '. Possession of tick c and knowledge 
of the private delegation key constitute 
sufficient proof of delegation from C to 
5. However, if such delegation from C 
to 5 is not needed, 

is sent in step 3 instead of [kj) k \ this 
acts as an authenticator for proving 
C’s knowledge of k d ' without revealing 
it. In steps 4 and 5, 5 requests the 
public key certificate of C, which is 
used to verify tick c in step 6. In step 7,5 
returns [T + 1}* to C to complete mu- 
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tual authentication between C and S. 

Since SPX is a relatively recent pro¬ 
posal, its security properties have not 
been studied extensively. Such study 
would be necessary before it could be 
generally adopted. 

Although SPX offers services similar 
to those of Kerberos, its elimination of 
on-line trusted authentication servers 
and the extensive use of hierarchical 
trust relationships are intended to make 
SPX scalable for very large distributed 
systems. 


W ith the growth in scale of dis¬ 
tributed systems, security has 
become a major concern — 
and a limiting factor — in their design. 
Security has been strongly advocated as 
one of the major design constraints in 
both the Athena project at the Massa¬ 
chusetts Institute of Technology and 
the Andrew project at Carnegie Mellon 
University. Most existing distributed sys¬ 
tems, however, do not have a well- 
defined security framework and use au¬ 
thentication only for their most critical 
applications, if at all. 


Most of the protocols we present are 
practically feasible, and their adop¬ 
tion and use should be just a matter of 
need. 

The complexity of understanding and 
managing the security of a distributed 
system requires a formal approach that 
allows precise specifications of both the 
system’s architecture and its protocols. 
Lam, Shankar, and Woo 12 have pro¬ 
posed a basis for developing such an 
approach. ■ 
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High-Performance Logic 
Programming with the 
Aquarius Prolog Compiler 


Peter Van Roy, Digital Equipment Corporation 
Alvin M. Despain, University of Southern California 


The enjoyment of the tools one works with is, of course, an essential ingredient of successful work. 

— D. Knuth, The Art of Computer Programming, Vol. 2 


This optimizing 
compiler outperforms 
other Prolog 
implementations and 
reduces the 
performance gap 
between systems based 
on logic programming 
and those based on 
imperative languages. 


T he goal of logic programming is to let programmers work at a high level 
I of abstraction. Prolog, the most popular logic-programming language, 
attempts to make programming practical in a subset of first-order logic. 
The advantages of Prolog are its expressive power (ease of programming and 
compact code) and its declarative semantics (ease of program transformation and 
transparent parallelism). 

Commercial Prolog systems are robust and useful for solving many problems, 
but they are often an order of magnitude slower than systems implemented with 
popular imperative languages such as C. The goal of our work is to reduce this 
performance gap. Our hypothesis is that Prolog can be implemented as efficiently 
as an imperative language by compiling the more powerful features of logic 
programming only where they are needed, and then only in the simplest form. 

To test this hypothesis we have designed and built Aquarius Prolog, a high- 
performance compiler. The driving force in its design is to encode each occurrence 
of a general Prolog feature as simply as possible. This article describes the structure 
of the Aquarius compiler and evaluates its performance. We begin with some 
background on logic programming, then discuss the Prolog language in more 
detail, including (1) the principles of its compilation on the popular Warren 
Abstract Machine execution model and (2) the factors that limit Prolog perfor¬ 
mance. We go on to present an overview of our compiler, giving its structure and 
the principles underlying its high performance. We then compare our system with 
two popular high-performance commercial systems and with two implementations 
of C. We conclude with an overview of ways to extend this work. 


Logic programming 

The motivation underlying logic programming is the idea of letting program¬ 
mers describe what they want separately from how to get it. This idea is based on 
the insight that any algorithm consists of two parts: a logical specification (the 
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logic ) and a description of how to exe¬ 
cute this specification (the control). This 
is summarized by Kowalski’s well-known 
equation: 

algorithm = logic + control. 1 

The goal is to have the system automat¬ 
ically provide most of the control and 
cleanly separate the remaining control 
from the logic. This places logic pro¬ 
gramming a level of abstraction above 
imperative programming in languages 
like C or Pascal, because the system 
handles more low-level details. 

Many logic languages have been pro¬ 
posed. Prolog, the most popular of them, 
was created to solve problems in natu¬ 
ral language understanding. It has suc¬ 
cessful commercial implementations and 
an active user community. Programming 
in Prolog is well understood and a con¬ 
sensus has developed regarding good 
programming style. The semantics of 
Prolog strike a balance between effi¬ 
cient implementation and logical com¬ 
pleteness. 23 It is a naive theorem prover 
but a useful programming language be¬ 
cause of its mathematical foundation, 
its simplicity, and its efficient imple¬ 
mentation of the powerful concepts of 
unification (pattern matching) and back¬ 
tracking (search). 

Prolog is being applied in such di¬ 
verse areas as expert systems, natural 
language understanding, theorem prov¬ 
ing, deductive databases, CAD tool de¬ 
sign, and compiler writing. It is a good 
choice for any application that has large 
amounts of rapidly changing, complex, 
but easily coded knowledge. Examples 
of successful applications are AUNT, a 
universal netlist translator; Chat-80, a 
natural language query system; and di¬ 
verse in-house expert systems and CAD 
tools. Grammars based on unification 
have become popular in natural lan¬ 
guage analysis. Variants of Prolog are 
the basis of important work in the area 
of languages with implicit parallelism. 
Our research group has used Prolog 
successfully in tool development for 
architecture analysis and synthesis, in 
compilation, and in silicon compilation. 

Prolog language 

Here, we briefly introduce Prolog and 
how to program in it. For more informa¬ 
tion, see Clocksin and Mellish 4 and Ster¬ 
ling and Shapiro. 5 



Prolog semantics strike 
a balance between 
efficient implementation 
and logical 
completeness. 


In Prolog, a program is a set of claus¬ 
es (logical sentences) written in a sub¬ 
set of first-order logic called Horn clause 
logic, which means that they can be 
interpreted as (/-statements. A predi¬ 
cate is a set of clauses that defines a 
relation. All the clauses have the same 
name and arity (number of arguments). 
Predicates are often referred to by the 
pair, name/arity. For example, the pred¬ 
icate, in_tree/2, defines membership in 
an ordered binary tree and can be de¬ 
fined with the following three clauses: 

in_tree(X,tree(V,Left,Right)) :- 
X = V. 

in_tree(X,tree(V,Left,Right)) :- 
X < V, in_tree(X,Left). 

in_tree(X,tree(V,Left,Right)) :- 
X > V, in_tree(X,Right). 

where :-means “if,” comma (“,”) means 
“and,” variables begin with a capital 
letter, and tree(V,L,R) is a compound 
object with three fields. 

In English, this definition can be in¬ 
terpreted: “X is in a tree if it is equal to 
the node value (first clause), or less 
than the node value and in the left 
subtree (second clause), or greater than 
the node value and in the right subtree 
(third clause).” 

Prolog can directly execute the 
in_tree/2 definition in several different 
ways, all of which satisfy the logical 
interpretation. The differences lie in 
which arguments are inputs and which 
are outputs. The definition can be used 
both to insert and to look up X in a tree. 
For example, load the definition of 
in_tree/2 in a Prolog system and type 
the query 

in_tree(2,T), in_tree(3,T), 
in_tree(l,T). 

The output is 


T = tree(2, tree(l, LI, Rl), 
tree(3, L3, R3)). 

That is, the system has created a tree T 
containing the numbers 1, 2, and 3. 

The execution of Prolog proceeds as 
a simple theorem prover. Given a query 
and a set of clauses, Prolog attempts to 
construct values for the query variables 
that make the query true. Execution 
proceeds depth-first, so program claus¬ 
es are tried in the order they are listed 
and the goals (that is, calls to predi¬ 
cates) inside each clause are invoked 
from left to right (that is, in the same 
sequence that procedures are called in 
imperative languages). This strict order 
imposed on the execution makes Prolog 
rather weak as a theorem prover but 
useful as a programming language, es¬ 
pecially since it can be implemented 
very efficiently — much more so than a 
more general theorem prover. 

Programmer features. Prolog has four 
main features for programmers. 

Logical variable* In Prolog, a vari¬ 
able is a name of a data object. Initially, 
its value is unknown, but it can become 
known by instantiation. Because the 
variable is logical, it has the same value 
throughout the program, just like a vari¬ 
able in a logical sentence. Therefore, it 
can be instantiated only once (that is, it 
is single-assignment). This contrasts with 
imperative-language variables, which are 
names of storage locations. 

Prolog variables can be bound to oth¬ 
er variables. When a variable is instan¬ 
tiated, all the variables bound to it see 
its instantiated value. Variables can be 
passed as predicate arguments or as ar¬ 
guments of compound data objects. This 
is the basis of a powerful programming 
technique: incrementally instantiating 
partial data structures. 

Dynamic typing. Variables can hold 
values of any type. This feature is like 
Lisp but unlike common imperative lan¬ 
guages. The values are called terms. 
Common types are 

• atoms (unique constants, for exam¬ 
ple, foo, abed); 

• numbers; 
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• lists (like Lisp lists but written with 
square brackets, for example, 
[HeadITail], [a,b,c,d]); and 

•structures (for example, tree 
(X,L,R), quad(X,C,B,F)). 

Structures are compound types, similar 
to C structures or Pascal records; like 
predicates, they have a name (the func¬ 
tor) and a fixed number of arguments 
(the arity). New compound types can be 
created at runtime. 

Unification. Unificatiorris a pattern¬ 
matching operation that finds the most 
general common instance of two data 
objects. (For a formal definition of uni¬ 
fication, see Lloyd. 3 ) It is used to build 
and access compound terms and to bind 
variables. Unification matches com¬ 
pound terms of any size in a single oper¬ 
ation. As a part of matching, the vari¬ 
ables in the terms are instantiated to 
make them equal. In Figure 1, an exam¬ 
ple unification of s(X,Y,a) and s(Z,b,Z) 
matches X with Z, Y with b, and a with 
Z. After the unification, Y equals b, 
both X and Z equal a , and the unified 
term is s(a,b,a). 

Backtracking. During execution, Pro¬ 
log attempts to satisfy the clauses (that 
is, find values of variables that make 
them true) in the order listed in the 
program. When a predicate with more 
than one clause is invoked, the system 
remembers this in a choice point. If the 
system cannot make a clause true (be¬ 
cause unification attempts to bind a vari¬ 
able to two values), we say that execu¬ 
tion fails, and the system backtracks to 
the most recent choice point (that is, it 
undoes the bindings made trying to sat¬ 
isfy that clause). It then tries the next 
clause, which may give different values 
to variables. 

Programming style and execution ef¬ 
ficiency. The Prolog language only ap¬ 
proximates the ideal of separating logic 
from control. Despite this, it is possible 
to write efficient programs that are still 
logical specifications, if the program¬ 
mer follows two disciplines: 

• The execution order must be taken 
into account. For example, in inductive 
specifications the base case must some¬ 
times be listed first to avoid an infinite 
loop. 

• Good data structures and algorithms 
must be used. A simple specification is 


s(X, Y, a) X = Z X = a 

s(Z,b,Z) a = Z Z = a 


Figure 1. An example of unification. 


generally not an efficient program. Com¬ 
plex specifications can be vastly more 
efficient while retaining identical se¬ 
mantics. 

An elegant programming style has 
evolved, consistent with these disci¬ 
plines. Retaining a program’s declara¬ 
tive reading while making it efficient is 
an art. We illustrate this by giving two 
specifications of list sorting. The first 
specification is straightforward: 

sort(InList, OutList) :— 

permute(InList, OutList), 
ordered(OutList). 

permute([], []). 

permute(InList, [XIOutList]) :- 
delete(InList, X, Del), 
permute(Del, OutList). 

delete([XIList], X, List). 

delete([XIList], Y, [XIDel]) :- 
delete(List, Y, Del). 

ordered([]). 

ordered([A]). 

ordered([A,BIList]) :- 
A < B, ordered ([BI List]). 

(Here, [] denotes the empty list, and 
[HeadITail] denotes a list with first ele¬ 
ment Head and remainder Tail.) 

This specification defines a sorted list 
as an ordered permutation of the origi¬ 
nal list. It is directly executable, and an 
inductive argument can prove its cor¬ 
rectness. However, its worst-case exe¬ 
cution time increases exponentially with 
the length of the input list. In general, 
converting this kind of specification 
automatically to an efficient algorithm 
such as quicksort or mergesort is impos¬ 
sible (although systems that have de¬ 
layed evaluation, such as NU-Prolog, 
can prune large parts of the search space 
and execute it faster). Efficiency re¬ 
quires writing a more involved specifi¬ 
cation —one that has algorithmic knowl¬ 
edge embedded in it. One of the most 


efficient sorting algorithms in Prolog is 
mergesort. 

Figure 2 presents one possible merge¬ 
sort specification. This definition is both 
declarative and deterministic. When 
executed as an algorithm, it achieves 
the standard 0(n log n) worst-case time 
bound for mergesort. The additional 
two arguments of sort/4 carry informa¬ 
tion about partial data structures. This 
information is used to improve effi¬ 
ciency. 

Prolog implementation 
and the Warren 
Abstract Machine 

Robert Kowalski and Alain Colmer- 
auer conceived the Prolog language in 
the early 1970s. Colmerauer and his 
associates in France developed the first 
implementation as a byproduct of re¬ 
search into natural language understand¬ 
ing. This implementation was an inter¬ 
preter. David Warren developed the 
first compiler in 1977. This implementa¬ 
tion made Prolog a viable language. In 
1983, Warren developed an execution 
model, the Warren Abstract Machine, 2 
for compiled Prolog; it has become the 
de facto standard implementation tech¬ 
nique. The WAM defines a high-level 
instruction set that maps closely to Pro¬ 
log source code. 

Two of the fastest systems available 
today, BIM Prolog and Quintus Prolog, 
are based on the WAM. Both have ex¬ 
tended it for efficiency. For portability 
and compact code, Quintus uses a thread¬ 
ed-code implementation with about a 
thousand specialized instructions. For 
speed, BIM does macro-expansion into 
native code. Neither BIM nor Quintus 
does any global optimizations. Later in 
this article, we compare the performance 
of BIM and Quintus with that of Aquar¬ 
ius Prolog. 

The WAM defines a mapping between 
the terminology of logic and a sequen¬ 
tial machine, shown in Figure 3. Predi¬ 
cates correspond to procedures. Proce¬ 
dures always have a case statement as 
the first part of their definition. Clauses 
correspond to the arms of this case state¬ 
ment. Variables are scoped locally to a 
clause. (Global variables exist; howev¬ 
er, their use is discouraged because they 
are inefficient.) Goals in a clause corre¬ 
spond to calls. Unification corresponds 
to parameter passing and assignment. 
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Other features — for example, back¬ 
tracking, the single-assignment nature 
of variables, and the modification of 
control flow with the cut operation — 
do not map directly. 

The WAM’s efficiency is based on 
five ideas: 

Represent data efficiently. Data are 
represented as objects that fit in a regis¬ 
ter and consist of two parts: the tag field 
and the value field. The WAM uses this 
representation to implement dynamic 
typing. The tag field gives the data type. 
The value field serves different purpos¬ 
es in different types. It gives the value of 
integers and the address of unbound 
variables and compound terms (lists and 
structures). It also ensures that each 
atom has a value different from all oth¬ 
er atoms. Unbound variables are imple¬ 
mented as self-referential pointers, that 
is, they point to themselves. When two 
variables are unified, one of them is 
modified to point to the other. There¬ 
fore, it may be necessary to follow a 
chain of pointers to access a variable’s 
value. This is called dereferencing the 
variable. 

Specialize unification. Most uses of 
unification are special cases of the gen¬ 
eral unification algorithm and can be 
compiled into more efficient code. For 
example, consider the following clause, 
which is part of a queue-handling pack¬ 
age: 

% queue(X,Q). 

% Q is a queue containing the 
single element X. 

queue(X, Q) :- 
Q = q(s(0),[XIC],C). 

(The notation P = Q means to unify P 
and Q.) 

A queue containing a single element 
is represented as the compound term 
q(s(0),[XIC],C). The complexity of uni¬ 
fying this term is typical of real pro¬ 
grams. Compiling this into WAM re¬ 
sults in code that executes as if the 
original clause had been defined as fol¬ 
lows, with the nested term q/3 com¬ 
pletely flattened: 

queue(X, Q):- Q = q(A,B,C), 

A = s(0), B = [XIC], 

This compiles into the WAM instruc¬ 
tions listed in Figure 4. The compiler 
expands the unification’s nested struc- 


% sort(List, N, Sort, Rest) 

% Sort is a sorted list of the first N elements of List. 

% Rest contains the remaining elements. 
sort(List, 0, [], List). 
sort([XIList], 1, [X], List). 
sort(List, N, Sort, Rest) :- 
N>1, 

NL is N//2,% Integer division 
NR is N-NL, 

sort(List, NL, Sortl, Mid), 
sort(Mid, NR, Sort2, Rest), 
merge(Sortl, Sort2, Sort). 

% merge(Ll, L2, L) 

% If LI and L2 are sorted, then L is their sorted union, 
merge([], L, L). 
merge(L, [], L). 

merge([XILl], [YIL2], [X1L]):- X<Y, merge(Ll, [YIL2], L). 
merge([XILl], [YIL2], [YIL]):- X>Y, merge([XILl], L2, L). 


Figure 2. Specification for mergesort. 


Prolog Imperative language 


Set of clauses —► 
Predicate, set of clauses -<—► 
with same name and arity 

Clause, axiom < * • 


Goal invocation 
Unification 


Backtracking —► 


Logical variable 
Recursion 


Program 

Procedure 

If statement, series of precedure calls, one 
arm of a nondeterministic case statement 
Procedure call 

Parameter passing, assignment, 
building and accessing compound objects, 
dynamic memory allocation, conditional 
branching 

Continuation passing, 
execution state manipulation 
Pointer manipulation 
Iteration 


Figure 3. Mapping between Prolog and an imperative language. 


procedure queue/2 


get_structure q/3,A2 

% Q=q( 


(Start unification of q/3) 

unify_variable X2 

% 

A, 


unify_variable X3 

% 

B, 


unify_variable X4 

% 

C) 


get_structure s/l,X2 

% A=s( 


(Start unification of s/1) 

unify _constant 0 

% 

0) 


get_list X3 

% B= 


(Start unification of list) 

unify_value A1 

% 

[X 


unify_value X4 

% 

1C] 


proceed 

% 


(Return to caller) 


(A1 and A2 are registers holding the arguments X and Q. 
XI, X2,. . . are temporary registers.) 


Figure 4. WAM compiled instructions. 
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Three kinds of data objects on the stacks 
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Prolog 
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(data 
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Global 
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Figure 5. WAM and BAM data structures. 


ture into a sequence of operations that 
do special cases of the general unifica¬ 
tion operation. These operations are 
encapsulated in the get and unify in¬ 
structions. 

Exploit determinism. It is often pos¬ 
sible to convert backtracking into con¬ 
ditional branching, which is much more 
efficient. The WAM can look at the first 
argument of a predicate, then do multi¬ 
way branching on its tag and hashing on 
its value to eliminate clauses that could 
not possibly unify with the goal. 

Map Prolog variables to registers. The 

variables occurring in a clause are par¬ 
titioned into three classes — tempo¬ 
rary, permanent, and void—depending 
on their lifetimes. Temporary variables 
do not need to survive across procedure 
calls, so they can be stored in machine 
registers. Permanent variables are stored 
in environments (that is, stack frames) 
local to a clause. Void variables have no 
lifetime and often need no storage. 

Map the execution onto multiple 
stacks. The stack-based structure allows 
fast recovery of memory on backtrack¬ 
ing. As a result, many applications do 
not need a garbage collector. Three 
stacks are used to hold the three WAM 
data objects: environments (used to hold 


variables local to a clause), choice points 
(similar to closures, they encapsulate 
machine state for backtracking), and 
terms (lists and structures, the compound 
data of Prolog). The stacks holding these 
objects are known respectively as the 
environment stack, the choice-point 
stack, and the global stack (also called 
the heap). Memory is recovered on the 
environment stack with environment 
trimming, a generalized last-call opti¬ 
mization. Often the environment and 
choice-point stacks are combined into a 
single stack called the local stack. Two 
other stacks, the trail and the push¬ 
down list, complete the model, as shown 
in Figure 5. The trail is used to save the 
addresses of bound variables that have 
to be unbound on backtracking. Saving 
the addresses is called trailing, and re¬ 
storing the variables to unbound is called 
detrailing. The push-down list is used 
during the unification of nested com¬ 
pound terms. 

Prolog performance 
limits: Beyond the WAM 

Prolog implementations have pro¬ 
gressed in execution efficiency with the 
development of the WAM. However, 
on the basis of speed alone, these sys¬ 


tems are not yet competitive with im¬ 
perative languages. There are various rea¬ 
sons for this: 

• The WAM is an elegant mapping of 
Prolog to a sequential machine, but it is 
too coarse-grained for much optimiza¬ 
tion. The best commercial systems have 
extended it (that is, added specialized 
instructions) to improve performance, 
but this approach is limited. 

•The majority of predicates written 
by human programmers are intended to 
give only one solution; that is, they are 
deterministic. Measurements of Prolog 
applications support this assertion. These 
predicates are, in effect, case statements; 
yet they are too often compiled ineffi¬ 
ciently using backtracking, which im¬ 
plies saving the machine state and re¬ 
peated failure and state restoration. 

• Programming style greatly affects a 
program’s efficiency. Prolog program¬ 
ming is at a high level of abstraction, so 
it hides many details of the implementa¬ 
tion from the programmer, making it 
difficult to improve efficiency when it is 
important to do so. For example, adding 
a single cut (a language feature that in¬ 
creases a program’s determinism) can 
make the difference between a program 
that runs fast and one so slow that it is 
unusable. 

• The single-assignment nature of Pro¬ 
log (that is, a variable can only be as¬ 
signed one value in forward execution) 
makes it time-consuming to modify large 
data structures incrementally. In the 
worst case, they have to be copied each 
time. This copy avoidance problem is a 
special case of the general problem of 
efficiently representing time in logic. It 
is impossible to use large data structures 
with the same efficiency as in procedural 
languages unless the compiler can intro¬ 
duce destructive assignment (overwrit¬ 
ing of memory locations) in the imple¬ 
mentation. 

•General-purpose architectures are 
designed for imperative languages. To 
run Prolog equally well, either the com¬ 
piler must do more work or the architec¬ 
ture must be modified. 

For these reasons, writing efficient 
programs that retain the declarative read¬ 
ing of logic is not always possible. As a 
result, programmers may be tempted to 
use fast nonlogical “features.” We strong¬ 
ly oppose this programming style. We 
believe it should be possible to write in 
pure Prolog and not be penalized for it. 
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Figure 6. The Aquarius system compilation path. 
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Figure 7. Structure of the compiler. 


Our hypothesis is that Prolog can in¬ 
deed be implemented as efficiently as 
imperative languages — that it will run 
as fast as imperative languages for pro¬ 
grams having a direct imperative mean¬ 
ing and that it will use the more power¬ 
ful Prolog features only where they are 
needed. We have followed both hard¬ 
ware and software approaches to test 
this hypothesis. The Aquarius compiler 
was developed simultaneously with a 
new architecture, the very large scale 
integration Berkeley Abstract Machine 
(VLSI-BAM). Interaction between 
these two designs during development 
has significantly improved both. For a 
description of the VLSI-BAM architec¬ 
ture and a cost/benefit analysis of its 
features, see Holmer et al. 6 

Aquarius Prolog 
compiler 

The driving force in the Aquarius 
compiler’s design is to encode each oc¬ 
currence of a general Prolog feature as 
simply as possible. The design is based 
on four principles: 

(1) Reduce instruction granularity. 
Generating efficient code requires an 
execution model and instruction set ca¬ 
pable of expressing the desired optimi¬ 
zations. The execution model for the 
Aquarius compiler is the Berkeley Ab¬ 
stract Machine. The BAM is designed 
to retain the good features of the WAM, 
but its instruction set is more like a 
sequential machine architecture. The 
compiler does not use the WAM during 
compilation, but instead compiles di¬ 
rectly to the BAM. 

(2) Exploit determinism. The Aquar¬ 
ius compiler incorporates techniques to 
compile deterministic predicates with 
efficient conditional branches. A deci¬ 
sion graph is created for each predicate. 
The compiler exploits type information 
derived by global analysis to simplify 
the graph as much as possible. The graph 
is created in an architecture-indepen¬ 
dent way through the concept of test 
sets, which define a mapping between 
Prolog and an architecture. 

(3) Specialize unification. All occur¬ 
rences of unification are compiled to 
the simplest possible code. In particu¬ 
lar, variable binding is simplified through 
the concept of uninitialized variables — 
unbound variables that are not aliased 


(that is, not bound to any other vari¬ 
able). 

(4) Do global analysis. The compiler 
includes a simple global analysis mod¬ 
ule that infers type information about 
predicates. This supports the previous 
two principles. 

Aquarius compiles Prolog in three 
stages, as shown in Figure 6. First, the 
compiler produces code for the BAM, 
our abstract machine. Second, it macro- 
expands the BAM code into the target 
processor’s native instruction set and 
builds the symbol table. In an optional 
third stage, the compiler optimizes this 
native code by reordering instructions 
and performing peephole optimizations. 
The system currently runs on the VLSI- 
BAM chip and either the Sparc, 
MC68020, or Mips processors. The com¬ 
plete Aquarius Prolog system, includ¬ 
ing source code, is available from the 
authors at aquarius@usc.edu. 

The compiler is written in about 10,000 
lines of Prolog code, excluding com¬ 
ments. (All program sizes in this article 
exclude comments.) The compiler’s back 
end, which converts BAM code to as¬ 
sembly for the target machine, is writ¬ 
ten in about 7,000 lines of Prolog code. 


The built-in predicates are mostly writ¬ 
ten in Prolog, about 6,500 lines. The 
small non-Prolog component is written 
mostly in BAM, with a few routines 
written in the instruction set of the tar¬ 
get machine. The system implements a 
superset of the built-in predicates listed 
in Clocksin and Mellish. 4 This book de¬ 
scribes a set of built-ins and a Prolog 
syntax, which are known together as the 
“Edinburgh standard.” This standard is 
not official; however, the International 
Standards Organization has a Prolog 
standard under development. 

The compiler implementation was 
guided by the quality of the code gener¬ 
ated during the development process. 
At each step; we added optimizations 
only for recognized flaws in the code. 
We maintained an informal priority 
queue of tasks ordered by 

(estimated benefits)/(estimated 
implementation effort). 

This approach seemed to result in the 
most effective use of available time, 
which was about three man-years. 

Aquarius compiler structure. Figure 
7 shows the compiler’s overall structure 
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as a series of four language transforma¬ 
tions. First, the Prolog source is trans¬ 
formed into a canonical form called ker¬ 
nel Prolog. Next, the kernel Prolog is 
improved by means of global analysis 
and source transformations to expose 
the determinism (that is, to convert the 
predicate into nested case statements). 
The optimized kernel Prolog is then 
compiled into BAM code, and finally, 
the BAM code is optimized. 

Throughout the compiler, logical for¬ 
mulas represent type information about 
variables. For example, the formula 

(integer(A),deref(A)) 

says that variable A is a dereferenced 
integer. During compilation, new infor¬ 
mation is continuously added to the for¬ 
mula, and inference based on the for¬ 
mula is used to simplify the generated 
code. This clean and powerful approach 
avoids redundant operations at run¬ 
time. For example, once A is derefer¬ 
enced, it will not be dereferenced again 
in the same predicate. 

For optimum performance, the sys¬ 
tem combines Prolog-specific compila¬ 
tion techniques together with standard 
techniques for low-level optimization. 
The kernel transformations are designed 
to generate a framework of good code 
that ignores simple inefficiencies, such 
as superfluous jump and move instruc¬ 
tions and occasional duplicate code. The 
BAM transformations obtain tight code 
from this framework. This “decoupling” 
keeps the design simple. 

The following subheads explain each 
transformation in Figure 7 in more de¬ 
tail. 

Transform to kernel Prolog. This stage 
transforms the raw Prolog input into 
kernel Prolog, a canonical form that 
represents its various syntactic features 
in a uniform way. This simplifies the 
rest of the compiler. A predicate in ker¬ 
nel Prolog is a clause (Head:-Disj), where 
the arguments of Head are distinct vari¬ 
ables and Disj is a single disjunction (a 
list of clauses separated by OR) con¬ 
taining no negations, if-then-else forms, 
nested disjunctions, or cuts. Unifica¬ 
tions in the head of the original predi¬ 
cate are represented as explicit unifica¬ 
tions in the clauses of the disjunction. 
Negations, if-then-else forms, and nest¬ 
ed disjunctions in the original predicate 
are converted into dummy predicates 
containing cuts. Cuts are implemented 


by a source transformation. Arithmetic 
expressions are flattened into primitive 
operations. 

Kernel transformations. This stage 
improves the kernel Prolog with a series 
of transformations. The two most im¬ 
portant are global analysis and deter¬ 
minism transformation. 

(1) Global analysis. This module uses 
abstract interpretation to derive types 
for the predicate arguments (discussed 
further under “Ideas in the Aquarius 
compiler.”) This module’s output is ker¬ 
nel Prolog annotated with type declara¬ 
tions. The module redoes part of the 
transformation to kernel Prolog in the 
light of the type information to increase 
the determinism that is easily accessi¬ 
ble. For example, the clause 

a(X,X,X). 

is first transformed to kernel Prolog: 

a(X,Y,Z)X = Y, X = Z. 

(We have simplified the notation for 
readability.) If analysis proves that X is 
unbound and both Y and Z are nonvari¬ 
able, then the above kernel Prolog hides 
the determinism by twice unifying an un¬ 
bound variable with a nonvariable. Do¬ 
ing the transformation again results in 

a(X,Y,Z)Y = Z, X = Y. 

In this version, the non variables Y and Z 
are unified, better exposing the deter¬ 
ministic check that is done. Since 
unification is commutative and associa¬ 
tive, both versions have identical se¬ 
mantics. 

(2) Determinism transformation. This 
module rewrites the program to make 
its determinism explicit; that is, it re¬ 
places shallow backtracking (trying claus¬ 
es in the same predicate) by conditional 
branching. It does this by rewriting the 
predicate into a series of nested case 
statements. Sometimes this is only par¬ 
tially successful; certain branches of the 
case statements may retain disjunctions 
that could not be converted into deter¬ 
ministic code. The module consists of a 
series of source transformations that 
bring the determinism closer to the sur¬ 
face, followed by a transformation that 
creates the case statements. The most 
important transformations are type en¬ 


richment, goal reordering, and deter¬ 
minism extraction. 

• Type enrichment. By looking at the 
type or the value of one or more argu¬ 
ments, the compiler can reduce the set 
of clauses that must be tried. To extract 
determinism, the compiler uses all ar¬ 
guments that have a known type. Often, 
global analysis derives sufficiently strong 
types to do a good selection; that is, the 
predicate can be compiled into deter¬ 
ministic code. However, if the predi¬ 
cate’s types are weak, then a source 
transformation is done to enrich them. 
The transformation uses the following 
heuristic: Define a good predicate argu¬ 
ment as one that is an argument of a 
unification not known always to suc¬ 
ceed (that is, neither argument in the 
unification is unbound). The predicate 
is enriched only if there are no nonvari¬ 
able good arguments. In that case, the 
lowest numbered good argument is cho¬ 
sen. To make this a generalization of 
the WAM’s selection, the first argu¬ 
ment is always picked if it is good, even 
if there are nonvariable good arguments. 
For example, if no types are known for 
this predicate 

a(a). 

a(b). 

then it is transformed into 

a(A) :- var(A), a_v(A). 

% If A is unbound. 

a(A):- nonvar(A), a_n(A). 

% If A is nonvariable. 

a_v(a). a_n(a). 

a_v(b). a_n(b). 

The predicate a/1 has been enriched 
with an unbound type (in a_v/l) and 
with a nonvariable type (in a_n/l). The 
compiled code is very different for 
a_v/l and a_n/l. By default, only one 
argument is enriched, since measure¬ 
ments show that enriching more than 
one often greatly increases code size 
and compilation time without signifi¬ 
cantly speeding up the resulting code. 
Occasionally, the enrichment results in 
some duplicate code. This is removed 
during the BAM transformation stage. 

• Goal reordering. The order of goals 
in each clause body is changed to make 
extracting determinism more effective. 
Tests and unifications that do not al¬ 
ways succeed are placed before unifica- 
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tions that are sure to succeed. The con¬ 
straint of maintaining language seman¬ 
tics restricts the reordering of goals. 

• Determinism extraction. This trans¬ 
formation tries to convert the predicate 
to a series of nested case statements. It 
is guided by a table that defines a map¬ 
ping between certain Prolog predicates 
and conditional branches in the target 
architecture (discussed further under 
“Ideas in the Aquarius compiler”). 

Kernel-Prolog-to-BAM compilation. 
This module separately compiles each 
predicate into BAM code. The follow¬ 
ing clause and disjunction operations 
are performed in order: 

(1) Clause compiler. The previous 
modules have generated the code im¬ 
plementing a predicate’s control flow. 
The remaining set of clauses is com¬ 
piled by the clause compiler. Its task is 
perhaps the most complex in the whole 
compilation, since it bridges the gap 
between kernel Prolog and BAM code. 
The two most important translations 
that it must do well are the compilation 
of goals (that is, procedure calls) and of 
unifications. Each of these does a large 
case analysis. In addition, the clause 
compiler allocates registers. 

• Goal compiler. Given a goal and 
type information about the goal’s argu¬ 
ments, this module generates the code 
to call the goal. It handles all combina¬ 
tions of uninitialized and initialized 
variables needed by and passed to the 
goal. 

• Unification compiler. Given a unifi¬ 
cation and type information about the 
arguments, this module generates the 
simplest possible code to implement the 
unification. Often this is a short sequence 
of instructions. In the general case, uni¬ 
fication code generation builds a tree of 
instructions. Each node of the tree has 
branches for the two modes of unifica¬ 
tion — read mode and write mode — 
and for failure. 

• Register allocation. This module al¬ 
locates registers and environment vari¬ 
ables. The algorithm is simple and ob¬ 
tains good results in most cases. It uses 
a scheme of “preferred” allocation, 
marking some variable pairs as prefera¬ 
bly allocated to the same register. For 
example, the instruction, move(X,Y), 
can be removed from the generated code 
if X and Y are allocated to the same 
register. The allocator attempts to satis¬ 


fy these preferences while avoiding con¬ 
flicts. 

(2) Disjunction compiler. A disjunc¬ 
tion is a list of clauses each of which may 
be tried by backtracking. Disjunctions 
remaining after determinism extraction 
are compiled into code that generates 
choice points. To minimize the size of 
the choice points (and hence the time 
required to create them), the only regis¬ 
ters saved are those needed in the dis¬ 
junction’s clauses after the first caluse; 
and for each disjunction clause, the only 
registers restored are those needed in 
the clause. 

BAM transformations. The preced¬ 
ing three transformations result in a 
framework of good code with many lo¬ 
cal inefficiencies. The BAM transfor¬ 
mations focus on these local inefficien¬ 
cies. The transformations include 
peephole optimization (with a window 
of three instructions), dead-code elimi¬ 
nation, jump elimination, duplicate-code 
elimination (reduce code size to mini¬ 
mize effects of kernel transformations), 
and choice-point elimination (a Prolog- 
specific optimization that increases de¬ 
terminism). 

Ideas in the Aquarius compiler. This 
section presents four important ideas 
that permeate the design. The first is 
the BAM execution model, which we 
describe here with a summary of its 
instructions. Then we discuss the com¬ 
pilation of deterministic predicates, the 
concept of uninitialized variables (which 
simplifies variable binding), and finally, 
global analysis. 

Berkeley Abstract Machine. The BAM, 
our execution model for Prolog, is de¬ 
signed to retain the WAM’s good fea¬ 
tures while allowing more optimization. 
The abstract machine evolved through 
interaction with the development of the 
compiler and the architectural design of 
the VLSI-BAM processor and through 
a requirement for portability. In the 
design of BAM, we looked at the WAM’s 
underlying memory model and derived 
the instruction set by seeing how the 
contents of memory change. The BAM 
retains types and data structures similar 
to those of the WAM. It retains the 
stacks of the WAM and uses a similar 
execution strategy. However, the in¬ 
struction set is completely different. The 
BAM is a load-store model that is ex¬ 


tended with tagged addressing modes 
and some Prolog-specific features. The 
BAM includes 

(1 ) Simple instructions. These are sim¬ 
ple register-transfer-level operations for 
a tagged architecture. They include 
move, push, conditional branch, and 
arithmetic instructions that implement 
most cases of unification and many built- 
in predicates. Many of the instructions 
were constructed in a top-down fashion 
by decomposing a unification algorithm 
into its building blocks, given basic ar¬ 
chitectural assumptions. 7 

(2) Complex instructions. There are 
five instructions that implement fre¬ 
quently used operations: dereferencing 
(following a pointer chain to its end), 
trailing (saving a variable’s address so it 
can be restored on backtracking), gen¬ 
eral unification (when the compiler can¬ 
not simplify the general case), choice- 
point handling (saving and restoring state 
for backtracking), and environment 
handling (creating and removing local 
stack frames). 

(3) Embedded information. This im¬ 
proves translation to the target machine’s 
assembly language. The information is 
expressed in two ways: with pragmas 
(which resemble instructions but are 
not executable) and with extensions that 
add arguments to the instructions. 

An example is the tag pragma, which 
gives the tag of a register: 

pragma(tag(r(l),tvar)). 

% Register r(l) contains a tvar 
tag. 

move([r(l)],r(0)). 

% Load indirect from register 
r(l). 

By specifying the tag at compile time, 
the tag can be subtracted during the 
load (using a register + displacement 
addressing mode). Therefore, the load 
can be completed in a single instruction 
on most general-purpose processors. 

An example of extensions is the unify 
instruction, which contains type infor¬ 
mation about its arguments: 

unify(r(0),r(l),?,nonvar). 

% Register r(l) is nonvariable. 

This gives no information about r(0) 
but says that r(l) is nonvariable. This 
makes the unification more efficient 
because the system does not have to 
check whether r(l) is unbound. 
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Test set 

Instruction 

A 

Branch if less than 

{A<B, A>B} 


{var(A), atomic(A), cons(A), structure(A)} 

Four-way branch on type 


Look up in hash table 

{A=a, A=b, A=c, A=d, A=e,A=f,A=g) 


Figure 8. Some test set examples. 


The BAM gains efficiency by per¬ 
forming dereferencing and trailing, two 
common Prolog operations, only 
through explicit instructions. The com¬ 
piler can therefore minimize their cost 
by performing them only when they are 
really needed. In the WAM, these oper¬ 
ations are performed implicitly by many 
instructions. 

Compilation of deterministic predi¬ 
cates. Aquarius uses the concept of a 
test set to compile predicates into code 
that uses conditional branches. A test 
set is a set of mutually exclusive predi¬ 
cates (that is, only one can be true at a 
time) that corresponds to a multiway 
branch in the target architecture. Each 
test in the set matches one direction of 
the multiway branch. Test sets are ranked 
according to their efficiency in the tar¬ 
get architecture. 

Most conditional branches in an ar¬ 
chitecture correspond to a test set. For 
example, a branch-if-less-than instruc¬ 
tion corresponds to the test set 

{A < B, A > B}. 

More complex branches, such as an n- 
way branch implemented by hashing, 
can also be represented as test sets. 
Figure 8 shows test set examples. The 
second and third examples correspond 
to WAM instructions. 

Given a predicate, the compiler pro¬ 
ceeds by first finding all test sets that 
contain tests used in the predicate. This 
depends on the types known for the 
predicate; for example, the unification 


X= a is only a test if X is nonvariable — 
that is, if the type formula implies 
nonvar(X). Then the compiler calcu¬ 
lates a “goodness” measure for each 
test set and uses the test set with the 
largest goodness first. The goodness 
measure is calculated heuristically; in 
the current implementation, each test 
set is weighted by an architecture-de- 
pendent goodness (which depends on 
how efficiently it is implemented in the 
architecture) and by the number of pos¬ 
sible outcomes (for example, hashing 
with a large number of cases is consid¬ 
ered better than a two-way branch). 
The compiler uses the best test set to 
convert the predicate into a case state¬ 
ment. The algorithm is called recursive¬ 
ly for each arm of the case statement to 
build a decision tree. During the BAM 
transformation stage, this tree is con¬ 
verted into a graph. 

To illustrate the use of test sets, con¬ 
sider the predicate 

max(A, B, C)A < B, C = B. 

max(A, B, C)A > B, C = A. 

This is one way to calculate the maxi¬ 
mum of A and B. It is compiled as 

max(A, B, C) 
if A > B then C = A 
else if A < B then C = B 
else (C = B or C = A). 

(We have simplified the notation for 
readability.) 

Aquarius executes this predicate com¬ 
pletely deterministically if A > B or 


A < B\ it creates a choice point only 
when A = B. The choice point is needed 
to maintain the operational semantics: 
Both clauses of the original predicate 
succeed when A = B, giving two identi¬ 
cal solutions. 

Simplifying variable binding with un¬ 
initialized variables. A major source of 
inefficiency in WAM implementations 
arises because variables are often creat¬ 
ed as unbound (that is, as self-referen¬ 
tial pointers) and are unified soon after¬ 
ward. Returning outputs from predicates 
is an example of this. It involves much 
unnecessary work; it would be faster 
just to reserve a memory location or a 
register and then write to it. 

Beer 8 first noticed this problem and 
proposed a solution called uninitialized 
variables — simplified variables that 
are bound by destructive assignment 
without dereferencing or trailing. He 
introduces several new tags for these 
variables and keeps track of them at 
runtime. Our scheme is inspired by his; 
however, we use the same tag for all 
variables and determine at compile time 
when it is safe to use destructive assign¬ 
ment to bind them. Our uninitialized 
variables are defined in two ways: 

(1) At the implementation level, an 
uninitialized variable is a location allo¬ 
cated to an unbound variable, but not 
given a value. 

(2) At the program level, an unini¬ 
tialized variable is an unbound variable 
that is not aliased (that is, there are no 
other variables bound to it). 

The location containing an uninitial¬ 
ized variable can either be a register or 
a memory word, resulting in two kinds 
of uninitialized variables, which we call 
uninitialized register and uninitialized 
memory variables. The first are regis¬ 
ters whose contents are ignored. The 
second are pointers to memory loca¬ 
tions whose contents are ignored. Stan¬ 
dard unbound variables are called ini¬ 
tialized variables; they are pointers to 
locations pointing to themselves. Fig¬ 
ure 9 illustrates the three kinds of un¬ 
bound variables. 

The compiler uses definition 1 to com¬ 
pile uninitialized variables efficiently. 
The global analyzer uses definition 2 to 
derive uninitialized variable types. The 
analyzer can derive both uninitialized 
register and uninitialized memory vari¬ 
ables. It can often determine that an 
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argument is uninitialized; for 
a representative set of pro¬ 
grams, it finds that 23 per¬ 
cent of all predicate argu¬ 
ments are uninitialized (this 
figure is independent of pro¬ 
gram size, unlike the other 
derived types). 

Table 1 gives minimum run¬ 
time costs in the VLSI-B AM 
for the three kinds of unbound 
variables. Costs are given for 
unification support (creation 
and binding) and for back¬ 
tracking support (trailing and 
detrailing). Binding an ini¬ 
tialized variable is expensive 
because the compiler must 
dereference the variable before it can 
store the new value in the memory cell. 
Binding an uninitialized memory vari¬ 
able reduces to a single memory-store 
operation. Binding an uninitialized reg¬ 
ister variable is free if it is created in the 
register that needs it. The cost of de¬ 
trailing (restoring a variable to an un¬ 
bound state on backtracking) is zero for 
uninitialized variables. For initialized 
variables it depends strongly on the ef¬ 
fectiveness of the compiler in generat¬ 
ing deterministic code. It is zero cycles 
if the variable does not have to be un¬ 
bound on backtracking and four cycles 
otherwise. 

Global analysis. It is difficult to ob¬ 
tain information about a program by 
executing it in its original form, because 
the range of possible behaviors is po¬ 
tentially infinite. To get around this prob¬ 
lem, the idea of abstract interpretation 
is to transform the program into a sim¬ 
pler form that allows practical analysis. 
After analysis, the inverse transforma¬ 
tion gives information about the ori¬ 
ginal program. The seminal work of 
Cousot and Cousot 9 explains the funda¬ 
mentals and mathematical underpinning 
of a general method based on this ap¬ 
proach. This method has been studied 
extensively and developed into a practi¬ 
cal tool for Prolog. 71012 

Our algorithm relies on Prolog’s 
depth-first execution order. We exe¬ 
cute the program, but instead of allow¬ 
ing variables to have any value, we re¬ 
strict them to values that are elements 
of a small finite set that is a lattice. A 
lattice is a partially ordered set where 
every nonempty subset has a least up¬ 
per bound and a greatest lower bound. 



tion. In other words, the set 
of values that a variable can 
have during execution is a 
subset of what is derived in 
the analysis. 

The following four items 
explain the analysis in more 
detail. 


Each of the lattice elements corresponds 
to a set of possible values (that is, a 
type) in the original program. We call 
this lattice an argument lattice, because 
it represents the possible values of a 
predicate argument. If the conditions of 
abstract interpretation hold, then the 
least fixpoint of the program’s execu¬ 
tion over the lattice (which is also known 
as symbolic execution) is a conservative 
approximation to the global informa- 


(1) Types derived by anal¬ 
ysis. Global analysis for Pro¬ 
log is fundamentally differ¬ 
ent from that of statically 
typed languages. Prolog re¬ 
quires types to be derived, 
whereas a statically typed lan¬ 
guage requires types to be 
checked. The most important 
information that can be de¬ 
duced about a predicate argument is 
whether it is an input or an output. We 
have experimented with four lattices in 
the analyzer, and the lattice we are cur¬ 
rently using has been chosen to give the 
most information while keeping analy¬ 
sis fast. 

During the analysis, our algorithm 
maintains two lattices for each argu¬ 
ment of each predicate in the program 
(see Figure 10). These lattices corre- 


Table 1. Cost of uninitialized variables. 


Type of Variable 

Cost (VLSI-BAM Cycles) 

For Unification For Backtracking 

Creation Binding Trailing Detrailing 

Uninitialized register 

0 

0 

0 0 

Uninitialized memory 

1 

1 

0 0 

Initialized variable 

2 

5 

2 0 or 4 
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Table 2. Timings for small programs (in milliseconds). 


Benchmark 

Aquarius 

Quintus 2.5 

BIM 3.1 Beta 

timeslO 

0.103 

0.345 

(3.3) 

0.36 

(3.5) 

nreverse 

0.440 

1.620 

(3.7) 

1.58 

(3.6) 

qsort 

0.520 

4.820 

(9.3) 

3.64 

(7.0) 

serialise 

1.640 

3.100 

(1.9) 

2.55 

(1.6) 

mu 

2.860 

7.040 

(2.5) 

5.97 

(2.1) 

queens_8 

3.200 

21.200 

(6.6) 

13.90 

(4.3) 

fast_mu 

3.600 

9.080 

(2.5) 

8.41 

(2.3) 

query 

15.100 

23.700 

(1.6) 

23.40 

(1.5) 

tak 

60.000 

1,120.000 

(18.7) 

704.00 

(11.7) 

sendmore 

80.000 

490.000 

(6.1) 

476.00 

(6.0) 

poly_10 

112.000 

417.000 

(3.7) 

261.00 

(2.3) 

zebra 

330.000 

423.000 

(1.3) 

376.00 

(1.1) 

Geometric mean of speedup ratio 

(3.7) 


(3.1) 

Standard deviation of mean 


(1.5) 


(0.9) 

Table 3. Timings for medium-size 

: programs (in milliseconds). 


Benchmark 

Aquarius 

Quintus 2.5 

BIM 3.1 Beta 

Not using built-in 

predicates 





prover 

3.20 

8.67 

(2.7) 

6.59 

(2.1) 

meta_qsort 

17.20 

49.60 

(2.9) 

49.10 

(2.9) 

nand 

57.00 

173.00 

(3.0) 

152.00 

(2.7) 

reducer_nowrite 

139.00 

312.00 

(2.2) 

309.00 

(2.2) 

chat_parser 

550.00 

1,157.00 

(2.1) 

970.00 

(1.8) 

browse 

2,500.00 

5,450.00 

(2.2) 

5,800.00 

(2.3) 

Geometric mean of speedup ratio 

(2.5) 


(2.3) 

Standard deviation of mean 


(0.2) 


(0.2) 

Using built-in predicates 





unify 

3.7 

18.3 

(4.9) 

22.80 

(6.2) 

flatten 

7.4 

13.6 

(1.8) 

9.61 

(1.3) 

crypt 

19.4 

21.7 

(1.1) 

18.50 

(1.0) 

simple_analyzer 

85.5 

180.0 

(2.1) 

174.00 

(2.0) 

reducer 

182.0 

405.0 

(2.2) 

359.00 

(2.0) 

chat 

2,100.0 

3,100.0 

(1.5) 

3,030.00 

(1.4) 

boyer 

3,100.0 

4,870.0 

(1.6) 

4,290.00 

(1.4) 

Geometric mean of speedup ratio 

(2.0) 


(1.8) 

Standard deviation of mean 


(0.5) 


(0.7) 

Geometric mean (all medium-: 

size programs) (2.2) 


(2.0) 


spond to the entry and exit types of the 
predicate, that is, to the variable’s value 
upon entering the predicate and upon 
successful exit from it. The lattice de¬ 
scribing the entire program is the Car¬ 
tesian product of the predicate lattices, 
which are themselves products of all the 
lattices of their arguments. 


In the entry and exit lattices, the top 
element, any, denotes the set of all pos¬ 
sible terms. The bottom element, im¬ 
possible, denotes the empty set (a pred¬ 
icate that is unreachable during 
execution). The element uninit denotes 
the set of uninitialized variables (un¬ 
bound variables that are not aliased; see 


previous section). The element ground 
denotes the set of ground terms (terms 
that contain no unbound variables). The 
element nonvar denotes the set of non¬ 
variables; rderef denotes the set of terms 
that are recursively dereferenced (that 
is, each term is dereferenced, which 
means that it is accessible without fol¬ 
lowing any pointers, and if it is com¬ 
pound, then all its arguments are recur¬ 
sively dereferenced); and ground+rderef 
denotes the set of terms that are both 
ground and recursively dereferenced. 

(2) Generating an uninitialized vari¬ 
able type. Here, we present a simple 
example of the generation of uninitial¬ 
ized variable types to give an idea of 
what abstract interpretation does. The 
analyzer generates uninitialized vari¬ 
ables whenever it deduces that an un¬ 
bound variable cannot be aliased to 
another. For example, consider the fol¬ 
lowing program fragment: 

pred(...) ..., nat(Z),... 

nat(X) X = s(Y), nat(Y). 

If Z is the first occurrence of that vari¬ 
able in the pred(...) clause, then it is a 
possible uninitialized variable: It is cer¬ 
tainly not aliased to any other variable. 
In the definition of nat(X), if X is unin¬ 
itialized, then the argument Y of the 
structure s(Y) may be uninitialized as 
well. This Y is passed on as an argument 
to nat(Y). Therefore, both calls of nat/ 
1 are with an uninitialized argument, so 
it is consistent to give the argument X 
an uninitialized variable type. 

It may happen that elsewhere in the 
program, nat(X) is called and X is not 
uninitialized (for example it might be 
nonvariable or aliased). In that case, 
the assumption that X is uninitialized is 
invalidated. This may invalidate assump¬ 
tions about other arguments of other 
predicates, so this information must be 
propagated. For correctness, it is neces¬ 
sary to iterate until a fixpoint is reached, 
that is, until symbolic execution of the 
program does not change any of the 
types. 

(3) Properties of the types. The exam¬ 
ple given above already suggests the 
types’ properties that are used during 
analysis. Here is a more complete list of 
these properties: 

• The property of being ground, unin¬ 
itialized, or recursively dereferenced 


64 


COMPUTER 















Table 4. The benchmarks. 


Benchmark 

Lines 

Description 

timeslO 

27 

Symbolic differentiation. 

nreverse 

10 

Naive reverse of a 30-element list. 

qsort 

19 

Quicksort of a 50-element list. 

serialise 

29 

Calculate serial numbers of a list. 

mu 

33 

Prove a theorem of Hofstadter’s “mu-math.” 

queens_8 

31 

Solve the eight-queens puzzle. 

fast_mu 

54 

An optimized version of the mu-math prover. 

query 

68 

Query a static database 
(with integer arithmetic). 

tak 

15 

Recursive integer arithmetic. 

sendmore 

43 

The Send+More=Money puzzle. 

poly_10 

86 

Symbolically raise a polynomial to the tenth 
power. 

zebra 

36 

A logical puzzle based on constraints. 

prover 

81 

A simple theorem prover. 

meta_qsort 

74 

A meta-interpreter running qsort. 

nand 

493 

A logic synthesis program using 
branch-and-bound search. 

reducer_nowrite 

298 

Same as reducer, but does not write its answers. 

chat_parser 

1,138 

Parse a set of English sentences. 

browse 

92 

Build and query a database. 

unify 

125 

A compiler code generator for unification. 

flatten 

158 

A source transformation to remove 
disjunctions. 

crypt 

64 

Solve a simple cryptarithmetic puzzle. 

simple_analyzer 

443 

A global analyzer analyzing qsort. 

reducer 

301 

A graph reducer based on combinators. 

chat 

4,801 

Natural-language query of a geographical 
database. 

boyer 

377 

An extract from a Boyer-Moore theorem 
prover. 


propagates through explicit unifications. 
If X is ground, uninitialized, or recur¬ 
sively dereferenced, then after execut¬ 
ing an explicit unification with a com¬ 
pound term (for example, X = s(A,B)), 
all of its variables (for example, A and 
B ) are ground, all of the new variables 
(for example, A and B) are uninitial¬ 
ized, or all of the new variables are 
recursively dereferenced. 

In the other direction, if all the vari¬ 
ables in the compound term are ground, 
then X is ground. If all the variables are 
recursively dereferenced, then X is re¬ 
cursively dereferenced if it was previ¬ 
ously uninitialized. 

•The property of being ground or 
nonvariable is independent of aliasing. 
For example, if X is ground, then it 
remains ground after the unification 
X = Y. This is not true of the other types. 

• An uninitialized variable is not alias¬ 
ed to any other variable. Lattice calcu¬ 
lations for uninitialized variables there¬ 
fore do not affect each other. 

(4) Measurement of the analyzer. 
Measurements show that many of these 
types exist and that exploiting them sig¬ 
nificantly improves code quality. 7 For 
the medium-size programs that do not 
use built-in predicates, analysis reduces 
execution time on the VLSI-B AM by 18 
percent and static code size by 43 per¬ 
cent. For all medium-size programs (see 
discussion and tables in the next sec¬ 
tion), the analyzer derives type infor¬ 
mation for 56 percent of all predicate 
arguments. It finds that on average 23 
percent of all predicate arguments are 
uninitialized, 21 percent of arguments 
are ground, 10 percent are nonvariables, 
and 17 percent are recursively derefer¬ 
enced. The sum of these three numbers 
is greater than 56 percent because an 
argument can have multiple types (for 
example, it can be both ground and 
recursively dereferenced). 

Compiler performance 

This section presents two sets of mea¬ 
surements of the Aquarius system. First, 
we compare its performance with that 
of Quintus Prolog and BIM Prolog, two 
high-performance popular commercial 
systems. Second, we compare it to two 
implementations of the C language. 

Comparison with other Prolog sys¬ 
tems. Tables 2 and 3 compare the per¬ 


formance of Aquarius Prolog with the 
high-performance commercial systems 
Quintus Prolog Version 2.5 and BIM 
Prolog Version 3.1 beta. All times are 
user times measured on a Sparcstation 
1+; system time is not counted. The 
benchmarks were run many times on an 
unloaded system and the minimum time 
was taken. No mode annotations are 
given for the benchmarks and they all 
run without garbage collection. All 
Aquarius times are for compiled pro¬ 
grams with global analysis, no garbage 
collection checks, and no arithmetic type 
checks. 

The Sparcstation 1+ is a low-cost 
machine based on a 25-MHz Sparc pro¬ 
cessor. Its memory system does not pro¬ 
vide single-cycle loads and stores. The 
minimum execution times of load and 
store instructions,are two and three cy¬ 


cles, respectively. A load is stalled by 
one cycle if the next instruction uses its 
result. A store is stalled by five cycles if 
the following instruction is also a store. 
For best performance, instructions must 
be reordered to separate the stores and 
to separate loads from the instructions 
that use theirresults. The Aquarius sys¬ 
tem contains an instruction reorderer. 

Table 4 describes the measurement 
benchmarks, which are grouped in three 
classes: small programs, medium-size 
programs that do not use built-in pred¬ 
icates, and medium-size programs that 
significantly use built-in predicates. The 
benchmarks are available from the au¬ 
thors and by anonymous ftp to 
arpa.berkeley.edu. The speedups for the 
benchmarks vary greatly. This is due to 
several factors: programming style, 
whether the program is deterministic or 
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backtrack-intensive, and the percent¬ 
age of time spent in built-in predicates. 

For the small programs, global analy¬ 
sis performs best. For the medium-size 
programs without built-ins, the speed¬ 
up is less because information is lost in 
the analyzer due to its inability to repre¬ 
sent aliasing (when two terms share a 
variable) and its limited type domain 
(many common types are not repre¬ 
sented). For the medium-size programs 
with built-ins, the speedup fluctuates 
more because of differences in how the 
built-ins are implemented and how of¬ 
ten they are used. 

For some benchmarks (such as tak 
and nreverse), the analysis derives es¬ 
sentially perfect types. The tak bench¬ 
mark is fast because it mainly does inte¬ 
ger arithmetic, which is compiled 
efficiently using uninitialized register 
types. The crypt and query benchmarks 
are dominated by multiplication and 
division (which are slow on the Spare- 
station). The chat benchmark uses the 
“setof” built-in predicate. The zebra 
benchmark does poorly for two rea¬ 
sons. First, it is dominated by back¬ 
tracking, which is inherently limited by 
the memory bandwidth. Second, it works 
by successively instantiating arguments 
of a compound data structure. The ana¬ 
lyzer does not have a representation for 
this operation, so it is compiled less 
efficiently. 

A good programming style is impor¬ 
tant to achieving top performance. The 
speedup of Aquarius Prolog is highest 
for programs 

• that manipulate ground terms (which 
do not contain unbound variables), 

• that always call the same predicate 
with the same argument types, and 

• whose determinism is visible through 
simple built-in predicates such as 
arithmetic and type checks. 

Writing programs in this way results in 
consistently higher speedups than those 
in Table 3. 

Within the WAM framework, there 
have been great efforts to make BIM 
and Quintus fast. Programs that use 
complex built-in predicates extensively 
(such as setof, bagof, or the recorded 
database) or that are highly backtrack- 
intensive will not do much better under 
Aquarius Prolog. Backtracking is in¬ 
herently limited by memory bandwidth. 
Built-in predicates in both BIM and 
Quintus are implemented efficiently in 


It is possible for a Prolog 
compiler to simplify 
general operations to the 
level of an imperative 
language. 


C and assembly. Aquarius Prolog incor¬ 
porates techniques to speed up both 
backtracking and built-in predicates, 7 
but the speedup factor is much less. In 
Aquarius Prolog, most built-in predi¬ 
cates are implemented in Prolog. This 
does not seem to cause a significant 
performance penalty. 

The static code sizes of Quintus, 
Aquarius, and BIM are in the approxi¬ 
mate ratios 1:2:5 for the small pro¬ 
grams. These ratios become 1: 5 : 5 for 
the medium-size programs. Aquarius 
code size increases for larger programs 
because of the limits of its global analy¬ 
sis. Quintus’ threaded-code implemen¬ 
tation has the most compact code. 

It takes the Aquarius compiler about 
36 minutes to compile chat_parser (1,138 
lines) when it is run under Quintus 2.5 
on a Sparcstation 1+. This includes the 
global analysis time, which is almost 
two minutes. The compilation time is 
approximately proportional to program 
size. We chose the internal data struc¬ 
tures of the Aquarius compiler for con¬ 
venience during development and not 
for execution efficiency. We expect that 
a large reduction in compilation time is 
possible by profiling the compiler and 
rewriting parts of it. Ralph Haygood 
has recently implemented a garbage 
collector in the runtime system, and we 
expect another reduction in compila¬ 
tion time when the compiler is run un¬ 
der itself. 

A comparison with C. This compari¬ 
son is not exhaustive — there are so 
many factors involved that we do not 
attempt to address the issue in its en¬ 
tirety. We intend only to dispel the no¬ 
tion that Prolog’s powerful features 
make its implementations inherently 
slow. We demonstrate that it is possible 
for a Prolog compiler to simplify the 
language’s general operations to the level 
of an imperative language. 


Comparison of two languages requires 
answers to the following questions: 

• How can implementations of differ¬ 
ent languages be compared fairly? For 
our comparison, we look exclusively at 
the language and ignore features exter¬ 
nal to it, such as user interface, develop¬ 
ment time, and debugging abilities. One 
way to compare implementation is to 
write the “best” programs in each lan¬ 
guage to solve selected problems, choos¬ 
ing the algorithms appropriate for each 
language. There are two disadvantages 
to this approach. First, different lan¬ 
guages are appropriate for different 
problems. Second, it is difficult to de¬ 
cide when the “best” program has been 
written. To avoid ambiguities, we com¬ 
pare algorithms, not programs. 

• Which algorithms will be implement¬ 
ed in both languages? Ideally, you would 
select a range of algorithms, from those 
most suited to imperative computations 
(for example, array and numeric com¬ 
putations) to those most suited to sym¬ 
bolic computation (for example, ma¬ 
nipulating large dynamic data objects 
and pattern matching). Prolog has an 
advantage at the symbolic end of the 
spectrum because implementing sym¬ 
bolic computations in an imperative 
language effectively requires implement¬ 
ing a Prolog-like system in that lan¬ 
guage. The programmer does the work 
of a compiler. At the imperative end of 
the spectrum, the efficiency of Prolog 
depends strongly on the ability of the 
compiler to simplify its general fea¬ 
tures. 

• What programming style will be used 
in coding the algorithms? We try to 
program in a style acceptable for both 
languages. This includes choosing data 
types in each language that are natural 
for that language. For example, dynam¬ 
ic data accessed by pointers is encour¬ 
aged in Prolog, whereas using static ar¬ 
rays is encouraged in C. It is possible to 
use dynamic data in C, but it requires 
more effort and is best restricted to 
those tasks that need it specifically. 

• How are architectural features tak¬ 
en into account? We use a general- 
purpose processor for measuring both 
implementations. This favors the im¬ 
perative language because general-pur¬ 
pose processors are designed to execute 
such languages well. The bias is evident 
for algorithms whose Prolog implemen¬ 
tation makes heavy use of Prolog-spe¬ 
cific features. To allow the reader to 
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make an informed judgment, we do not 
attempt to correct for this fact, but sim¬ 
ply note that by adding architectural 
features constituting 11 percent of the 
chip area to the VLSI-BAM (a pipe¬ 
lined processor similar to the Mips), we 
increase performance by 70 percent for 
programs that use Prolog-specific fea¬ 
tures. 6 Our architectural studies sug¬ 
gest that these features could be added 
to a future Mips processor. 

We compare small algorithms coded 
in both C and Prolog. Table 5 compares 
the execution speed of the Aquarius 
Prolog compiler with the standard Mips 
and the GNU C compilers on a 25-MHz 
Mips processor. (We do not use the 
Sparc because its register windows com¬ 
plicate the comparison.) In all cases, 
user time is measured with the Unix 
“time” utility. The two C versions are 
compiled twice — once using no optimi¬ 
zation and once using the optimization 
level that produces the fastest code. The 
Prolog versions are compiled with glo¬ 
bal analysis. We are careful to encode 
the same algorithms for both Prolog 
and C, in a natural style for each. The 
natural style in C is to use static data, 
whereas in Prolog all data is allocated 
dynamically. 

Table 5 gives measurements for tak, 
fib, and hanoi, which are recursion¬ 
intensive integer functions; and for 
quicksort, which sorts a 50-element list 
10,000 times. Prolog and C source code 
is available by anonymous ftp to 
arpa.berkeley.edu. 

Recursive functions are fast in Prolog 
for three reasons: 

•last-call optimization converts re¬ 
cursion into iteration, 

• environments (stack frames) are al¬ 
located per clause and not per pro¬ 
cedure as in C, and 
•outputs are returned in registers 
(they are of uninitialized register 
type). 

The last-call optimization allows func¬ 
tions with a single recursive call to exe¬ 
cute with constant stack space. This is 
essential for Prolog because recursion 
is its only efficient looping construct. 
Even though C does not need this opti¬ 
mization as much (it has constructs — 
For and While loops — to denote itera¬ 
tion explicitly), both the Mips and GNU 
compilers do last-call optimization. 
The two quicksort implementations 


Table 5. Comparing Prolog and C (in seconds). 


Benchmark 

Aquarius 

Mips C 


GNU C 



Prolog 

Unoptimized Optimized 

Unoptimized Optimized 

tak(24,16,8) 

1.2 

2.1 

1.6 

2.8 

2.7 

fib(30) 

1.5 

2.0 

1.6 

2.7 

2.2 

hanoi(20,1,2,3) 1.3 

1.6 

1.5 

2.1 

2.1 

quicksort 

2.8 

3.3 

1.4 

4.7 

2.2 


use exactly the same pivot elements. 
The C implementation uses an array of 
integers and does in-place sorting. The 
Prolog implementation uses lists and 
creates a new sorted list. The list repre¬ 
sentation needs two words to store each 
data element. Coincidentally, the Pro¬ 
log version is twice as slow as the Mips 
C version, the same as the ratio of the 
data sizes. 


T he main thrust of this work is to 
reduce the performance gap 
between the logic-programming 
language Prolog and imperative languag¬ 
es. The Aquarius system is significantly 
faster than previous Prolog implemen¬ 
tations. On a Sparcstation, it is two to 
three times faster than Quintus or BIM 
Prolog. For programs written in an ap¬ 
propriate style, it is at least four times 
faster. However, it is competitive with 
imperative languages only for a restrict¬ 
ed class of problems. 

There are many ways to extend this 
work and its results. One is through 
global analysis. When writing a pro¬ 
gram, a programmer often has definite 
intentions about the type and lifetime 
of data, even if these intentions are not 
made explicit. Therefore, it should be 
possible to derive much of this informa¬ 
tion from analysis. 11 In addition to log¬ 
ical properties, analysis should deter¬ 
mine all properties that are meaningful 
in the execution model (for example, 
the recursively dereferenced type, which 
has no simple logical meaning). 

Analysis is only part of the story; it is 
just as important to put the information 
to good use. Three important compila¬ 
tion techniques for using the informa¬ 
tion are 

(1) Determinism extraction. The cur¬ 
rent system only recognizes determin¬ 
ism caused by built-in predicates of three 


kinds (that is, unification, arithmetic 
comparison, and type checking). How¬ 
ever, determinism is often caused by 
user-defined predicates. 

(2) Compile-time garbage collection. 
Prolog creates three kinds of data ob¬ 
jects in memory: choice points, com¬ 
pound terms, and environments. When 
a data object becomes inaccessible, a 
new object can often reuse part of the 
old one. 

(3) Multiple specialization. Different 
calls of the same predicate frequently 
have different types for the same argu¬ 
ment. The predicate will run faster if it 
is compiled separately for each pattern 
of calling types. 

Finally, resolving language issues can 
extend this work. Two opposing factors 
in a language are its level of abstraction 
and its implementation efficiency. Log¬ 
ic-programming research has increased 
language power in many ways — for 
example, with more expressive logics, 
more intelligent control, and more pow¬ 
erful constraints. It may be possible to 
develop efficient implementations of 
these concepts by building on the ideas 
presented in this article. ■ 
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The efficiency of 
algorithms for 
automatic test pattern 
generation has not kept 
pace with increasing 
circuit size. Mapping 
the problem to 
parallel-processing 
machines may improve 
performance. 


G : enerating test patterns for testing digital circuits still consumes a signifi- 
I cant portion of design time. Techniques such as level-sensitive scan 
..I design are widely used to reduce the problem td one of testing combina¬ 
tional circuits, but even this problem has been shown to be NP complete. Gener¬ 
ation of test patterns for combinational logic is a search through the set of all input 
values to find one that causes the output of a good circuit to differ from that of one 
containing a fault. 

There are two basic approaches to solving the automatic test pattern generation 
(ATPG) problem: algorithmic test pattern generation and statistical, or pseudo¬ 
random, test pattern generation. In the algorithmic approach, a specific ATPG 
algorithm is used to generate a test for each fault in the circuit. Most of these 
algorithms can be proved to be complete; that is, they are guaranteed to find a test 
for a fault — as long as a test exists. However, this may involve searching the entire 
solution space, which is computationally expensive. Also, some ATPG algorithms 
do not keep track of the other faults in the circuit that are tested concurrently by 
the test for the target fault. In this case, generating tests for these faults results in 
excess computation. The resulting test set is also larger than required because of 
the redundant tests. 

Statistical test pattern generation, on the other hand, selects test patterns at 
random, or by using some heuristic, and uses fault simulation to determine the 
faults detected by the pattern. Test patterns are selected and added to the test set 
if they detect any previously undetected faults, until some required fault coverage 
measure or computation time limit is reached. This method finds tests for the easy- 
to-detect faults quickly but becomes less and less efficient as the easy-to-detect 
faults are removed from the fault list and only the hard-to-detect faults remain. In 
many cases, the required fault coverage cannot be achieved without excessive 
computation times. 

An efficient combined method for solving the ATPG problem uses statistical 
methods to find tests for the easy-to-detect faults on the fault list and switches to 
an algorithmic method to find tests for the remaining hard-to-detect faults. In 
either this method or the purely algorithmic method, a significant portion of the 
computation time will be spent generating tests for the hard-to-detect faults 
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The D-algorithm 


The first algorithm for AJPG that was 
proved complete is the D-algorithm intro¬ 
duced by Roth in 1966. 1 The D-algorithm 
includes a notation and a calculus with 
which a single stuck-at fault can be de¬ 
tected at a node in the circuit and propa¬ 
gated to a primary output of the circuit. 

This algorithm uses a five-valued logic, 
which consists of the logic values 0 and 
1, an unknown value X, and two addition¬ 
al values 0 and D. A D value signifies a 
logic value of 1 in the good circuit and 0 
in the faulty circuit. A 0 signifies a value 
of 0 in the good circuit and 1 in the faulty 
circuit. 

Each gate in the circuit has two D- 
cubes associated with it, the primitive 0- 
cube of a fault (pdcf) and a propagation 
D-cube (pdc). A pdcf is the set of inputs 
that produces an error signal on the output of that gate if it con¬ 
tains a fault. A pdc specifies the input values necessary to 
propagate an error signal on an input of a gate to the output. 
Figure A shows the pdcf’s and pdc’s of a two-input AND gate. 

The D-algorithm’s basic operation is the repeated intersection 
of the D-cubes necessary to perform the tasks required to test 
for a specific fault. These tasks consist of three processes: fault 
sensitization, fault propagation, and justification. Fault sensiti¬ 
zation is the process by which a circuit node is made to pro¬ 
duce an erroneous value as a result of the fault. Sensitization is 
accomplished by specifying an input combination for the circuit 
element containing the fault, using the pdcf’s that cause the 
output to take on the appropriate D value. Fault propagation is 
the process of propagating the 0 values to the primary outputs 
so that they can be observed. 

The list of circuit elements closest to the primary outputs that 
have a 0 or a 0 on the output is called the D frontier. The ob¬ 
jective of fault propagation is to advance the 0 frontier to the 
primary outputs. This process sensitizes all possible paths from 
the fault site to the primary outputs. This multiple-path sensiti¬ 
zation is necessary for the D-algorithm to guarantee complete¬ 
ness. 

During fault sensitization and fault propagation, certain circuit 
nodes are required to take on specific values. Establishing this 
value, or goal, on the node by placing values on the primary in¬ 
puts is called justification. The primary inputs that can be used 
to justify a goal are usually determined by backtracing through 
the circuit topology from the node in question to the primary in¬ 
puts. A value is chosen for one of these inputs, and a forward 
simulation-like process, called forward implication, is performed 


to see if this input assignment is consistent 
with satisfying the goal. If it’s not, a different 
value is chosen and the process is repeated. 
A test is finally generated when the fault is 
sensitized, a path for the fault to be observed 
at the primary outputs is sensitized, and all of 
the goals are justified. 

As an example of the D-algorithm, consid¬ 
er the circuit under test shown in Figure B. 
Assume that a test is being generated for a 
stuck-at-1 fault on node J, The first step is to 
fill in an initial test cube with a D on node J, 
as shown in test cube 0 in Figure B. This val¬ 
ue is then sensitized using a pdcf for the 
NOR gate (test cube 1). Next, all values im¬ 
plied on other circuit nodes by the previous 
step are filled in (test cube 2). The next step 
is to advance the 0 frontier by setting node K 
to 0. This implies values on nodes / and F 
(test cube 3). The 0 value on node / in turn implies 0 values on 
nodes E and H (test cube 4). The final step is to justify the 0 
value on node H by setting input C to a 0 value (test cube 5). 

If the values shown in test cube 1b were chosen when select¬ 
ing the pdcf for the initial fault, the implications of that choice 
would have caused a test to be impossible, as test cube 2b 
shows. This problem would have caused the algorithm to back¬ 
track to the last point a choice was made, pick the alternate 
choice, and proceed from there. In the D-algorithm, choices are 
available at many internal nodes in the circuit, and more than 
two choices can be present if there are gates in the circuit with 
more than two inputs. This fact greatly increases the size of the 
algorithm’s search space and makes backtracking more com¬ 
plex. The D-algorithm can be implemented as a recursive rou¬ 
tine that pushes or pops test cubes off a test cube stack as re¬ 
quired for forward progress or backtracking. 

Note that justification of two separate node assignments can¬ 
not be undertaken simultaneously, because if an inconsistency 
occurs, it will not be possible to determine which unique assign¬ 
ment caused it. Also, the original D-algorithm does not specify 
which process — fault sensitization or fault propagation — is to 
be undertaken first or whether justification is to be done in inter¬ 
mediate steps or deferred until the process ends. These details 
are left to the implementation. Unfortunately, the efficiency with 
which a test can be generated for a specific fault depends 
heavily on the order of these operations, and the most efficient 
order is determined by the circuit topology. For example, if in 
generating a test for J stuck-at-1 in the circuit of Figure B, fault 
propagation is done before selecting a pdcf, the unique value of 
0 required on node / will be discovered and the pdcf for the 
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Figure A. AND gate D-cubes. 


algorithmically. Therefore, finding a 
method to speed up this process should 
reduce the overall computation time 
considerably. 

Much research has gone into increas¬ 
ing the efficiency of algorithms for 
ATPG. However, the overall gains 
achieved through these improvements 
have not kept pace with increasing cir¬ 


cuit size, and computation times are 
still excessive. Another approach to 
reducing computation times is simply 
to use a faster machine. Parallel-pro¬ 
cessing machines are becoming avail¬ 
able for general use and are helping to 
solve other problems in computer-aid¬ 
ed design. This article surveys tech¬ 
niques now being explored to map the 


ATPG problem to parallel-processing 
machines. 

First, we discuss some of the more 
widely used serial ATPG algorithms and 
their suitability for implementation on a 
parallel machine. By serial algorithms 
we mean those developed to run on a 
conventional uniprocessor. Then we look 
briefly at the basic classes of parallel 
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faulty gate will be fixed. Test generation can then proceed with¬ 
out the possibility of backtracking. Finding the most effi¬ 
cient order for operations and detecting inconsistencies early 
in the process is the focus of most subsequently developed al¬ 
gorithms. 


Reference 


1. J.P. Roth, “Diagnosis of Automata Failures: A Calculus and a Meth¬ 
od," IBM J. Research and Development, Vol. 10, July 1966, pp. 
278-291. 
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Figure B. A D-algorithm example. 


machines to determine what characteris¬ 
tics they require of an algorithm if they 
are to implement it efficiently. Finally, 
we present several techniques that have 
been used to parallelize ATPG. These 
techniques fall into five major categories: 

• fault partitioning, 

• heuristic parallelization, 


• search-space partitioning, 
•functional (algorithmic) partition¬ 
ing, and 

• topological partitioning. 

In each category, we present an over¬ 
view of the technique, its advantages 
and disadvantages, the type of parallel 
machine it has been implemented on, 


and a brief summary of the reported 
results. 

ATPG algorithms 

We briefly describe several serial 
ATPG algorithms, including the D-al- 
gorithm, Podem, and Fan, in sidebars. 
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Podem 


The Podem (path-oriented decision-making) algorithm is an 
attempt to reduce the size of the solution space that must be 
searched. 1 Recall that the D-algorithm tries to assign a value 
to each circuit node. Conflicts can arise when values as¬ 
signed to different nodes cannot all be justified. Podem tries 
to eliminate these hidden conflicts by assigning values only to 
the primary inputs. 

The algorithm begins by trying to justify the D or D at the 
node under test, similar to the D-algorithm. This justification 
is done by assigning values to primary inputs that affect the 
node in question. These primary inputs are again found by 
backtracing through the circuit topology. When an input as¬ 
signment is made, a simulation-like process, called forward 
implication, is run to find all of the node values implied by the 
assignment. If this new input assignment is incompatible with 
the goal, the complementary value is tried. If the complemen¬ 
tary value assignment also conflicts, the algorithm backtracks 
efficiently to the previous input assignment. This process re¬ 
sults in an orderly search methodology that will implicitly 
search the entire input space. 

This search methodology can be represented by a binary 
search tree, as the accompanying figure shows. After the val¬ 
ue at the faulty node is justified, subsequent objectives are 
set up to propagate the D frontier along a path or paths to the 
primary outputs. The exact order in which this process occurs 


is again implementation dependent. The important point is 
that this strategy of assigning values only to primary inputs 
orders the search space. This procedure lets the search 
methodology prune the search tree implicitly and increase 
efficiency. 

Consider, for example, the figure below, a representation 
of the binary search space for a J s-a-0 fault in the circuit un¬ 
der test. This search space was constructed using the sim¬ 
ple heuristic of always trying the 1 logic value on a primary 
input first. Since assignment of the value 1 for node B in the 
left-hand subtree is inconsistent, all solutions that live below 
B in that part of the solution space can be pruned from the 
search tree. This ordering of the search space also lets it be 
divided into disjoint sections so that work on the different 
sections can proceed simultaneously. Note that the proces¬ 
sor must have access to the entire circuit topology and that 
only one goal may be justified at a time, as with the D-algo¬ 
rithm. 


Reference 

1. P. Goel, “An Implicit Enumeration Algorithm to Generate Tests 
for Combinational Logic Circuits,” IEEE Trans. Computers, Vol. 
C-30, No. 3, Mar. 1981, pp. 215-222. 



A Podem example. 


For a more detailed discussion of serial 
ATPG algorithms, see Kirkland and 
Mercer. 1 In this article, we consider only 
algorithms designed to generate tests 
for single stuck-at faults. These are phys¬ 
ical faults that cause a node in the cir¬ 
cuit to behave as if it were stuck at a 
logic 0 or a logic 1 level. The single 
stuck-at fault model is a simplification 
of the types of faults found in real cir¬ 
cuits, but empirical evidence shows that 
for most common implementation tech¬ 
nologies, it provides very high coverage 
of physical faults. 


When we understand the basics of the 
D-algorithm, we see that its paralleliza¬ 
tion would be difficult. No two opera¬ 
tions can be performed easily in parallel 
because the overall process is sequen¬ 
tial in nature. The algorithm needs ac¬ 
cess to almost the entire circuit topolo¬ 
gy at one time or another, and the path 
of the search through the solution space 
is not well defined, so dividing the search 
space into disjoint portions would be 
difficult. 

Podem, on the other hand, constructs 
a well-ordered representation of the 


solution space as a binary tree. This 
allows the search space to be divided 
easily into disjoint portions for evalua¬ 
tion by separate processors. In a later 
section we present several systems that 
use this method of parallelization. 

In most serial ATPG algorithms de¬ 
veloped to date, it is necessary to back¬ 
trace through the circuit topology to 
determine which inputs must be set to 
justify a certain node value. A heuristic 
determines how this backtracing is done. 
Also, to set a node that is the output of 
a gate, the inputs to that gate must be set 
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to certain values. The input value that is 
hardest to control is typically set first to 
try to reduce the number of backtracks. 
A heuristic also determines the selec¬ 
tion of this input. Heuristics for ATPG 
guidance is an active area of research, 
and many different approaches exist. 


Again, which heuristic results in the 
most efficient performance depends on 
the circuit topology. In many cases, 
switching to a different heuristic can 
significantly reduce the computation 
time required to find a test for a given 
fault. 2 


Parallel processors 

Parallel processors are computing 
machines comprising a number of pro¬ 
cessors that are separate entities capa¬ 
ble of performing disparate tasks. These 


Other serial algorithms 


The Fan algorithm 1 is similar to Podem but includes im¬ 
provements to increase its efficiency. The major goal of Fan 
is to reduce the number of backtracks in the search tree. 

This is accomplished using several techniques, including the 
consideration of fan-out branches in the circuit as a special 
case, hence the name Fan. 

To examine this concept, we must define several terms. A 
freeline is a circuit node that has no predecessors that are 
part of a fan-out loop. As such, freelines may have a unique¬ 
ly assigned value. In the accompanying figure, lines A 
through / are examples of freelines. A bound line is the op¬ 
posite of a freeline. Nodes Jand /Care bound lines and can¬ 
not have unique (independent) values assigned to them. 
Headlines are freelines that drive a gate that is part of a re- 
convergent fan-out loop. Node / in the figure is a headline. 

By definition, headlines can also be assigned values arbi¬ 
trarily because they are freelines and can always be inde¬ 
pendently justified. They can therefore be treated as primary 
inputs in the justification process. 

Identification of these nodes makes reconvergent fan-out 
loops much easier to handle. Once a test is found by treating 
headlines as primary inputs, the values on them can be justi¬ 
fied at the end of the test generation process. Fan also uses 
a multiple-backtrace procedure for reconvergent fan-out 
branches buried in the circuit to reduce the number of back¬ 
tracks that must be made in the search. For example, if a 
certain value is necessary at node L in the figure, and this 
circuit is part of some larger circuit, a single backtrace could 
be made along the path Values for inputs A 

and B could be chosen so that the goal is satisfied with a 
unique value on nodes / and K. Then if the value on K can¬ 
not be achieved with the value chosen for /, a significant 
amount of backtracking in the search tree can result. First, a 
multiple-backtrace procedure would 
backtrace both the L->J->/and /.-»/<->/ 
paths and determine the value needed 
at / to satisfy the goal. This value would 
then be set as a requirement for the 
justification of the value at node L. This 
process can increase the Fan algo¬ 
rithm’s efficiency significantly in a cir¬ 
cuit with numerous buried reconvergent 
fan-out loops. 

The Tops algorithm 2 takes Fan’s con¬ 
cept of the independent justification of 
headlines a step further by introducing 
a new type of node called a basis node. 

A basis node is a node that is the abso¬ 
lute dominator of all nodes that precede 
it in the circuit graph. The concept of 
dominator nodes comes from graph 
theory. A node dominates another node A Fan example. 


if all paths from that node to the root pass through the domi¬ 
nator. All freelines and headlines in a circuit are basis nodes, 
as are all points of total reconvergence. In the accompanying 
figure, the freelines A through / are basis nodes. Node L is 
also a basis node because it is a point of total reconver¬ 
gence. As a basis node, node L can take on any value re¬ 
quired to generate a test in the remainder of the circuit, and 
justification of that value can be deferred until the end of the 
test generation process. 

Independent justification of the basis nodes introduces an 
obvious opportunity for parallelism. More than one basis node 
can be justified simultaneously or in parallel with test genera¬ 
tion. Also, a processor need not know the topology of the cir¬ 
cuit that precedes the basis node until justification occurs. 

Other examples of Fan algorithm derivatives include 
Socrates, 3 which, like Tops, tries to reduce the size of the 
search space. Many of the systems can be viewed as effi¬ 
ciency improvements to the underlying algorithm and can be 
added to a parallel ATPG system once the basic algorithm 
has been parallelized. 
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Figure 1. A taxonomy of parallel processors. 


entities are linked by some 
mechanism so that they can 
exchange data and thus co¬ 
operate to solve a problem. 

Figure 1 shows a general tax¬ 
onomy of parallel processors. 

We can categorize paral¬ 
lel processors by the data and 
instruction streams upon 
which each processor acts. 

Processors in single-instruc¬ 
tion, multiple-data (SIMD) 
machines act on a single in¬ 
struction stream to manipu¬ 
late multiple data streams in 
parallel. Processors in mul¬ 
tiple-instruction, multiple- 
data (MIMD) machines act 
independently on separate 
instruction and data streams. 

For the most part, the paral¬ 
lel ATPG efforts that we dis¬ 
cuss are implemented on 
MIMD machines, except for 
the Connection Machine implementa¬ 
tion discussed later. For this reason, we 
limit our discussion in this section to 
MIMD machines. 

There are two basic types of MIMD 
machine: shared-memory systems and 
message-passing systems. These two 
system types vary greatly in their mem¬ 
ory organization and the method and 
speed with which information passes 
between the processors. 

Shared-memory machines have a sin¬ 
gle global memory accessible to all pro¬ 
cessors. Some machines also have a small 
amount of memory local to each pro¬ 
cessor, but typically each processor sees 
only one contiguous memory space. A 
major characteristic of most shared- 
memory systems is that access to data is 
independent of the processor making 
the request and is relatively fast — al¬ 
most as fast as typical memory access 
times in a uniprocessor system. Howev¬ 
er, when many processors are making 
simultaneous requests to a single mem¬ 
ory location or bank, and memory ac¬ 
cess becomes a bottleneck, access times 
can increase greatly. For this reason, 
physical memory layout and data orga¬ 
nization within the memory are critical 
to ensure that the memory system can 
handle as many simultaneous requests 
as possible. 

Programs designed for shared-mem¬ 
ory systems have some unique charac¬ 
teristics. Because of the easy access to 
global data, many global variables can 
beusedand program code can be shared. 


In the ATPG problem, the circuit topol¬ 
ogy information can be kept in a global 
data structure. The disadvantage of us¬ 
ing global variables is that maintaining 
data consistency is more difficult. Syn¬ 
chronization between processes must 
be maintained to ensure this data con¬ 
sistency. On the other hand, synchroni¬ 
zation is easier to maintain using glo¬ 
bally accessed semaphores. Because of 
this ease of synchronization, algorithms 
for shared-memory systems can use fine- 
grain parallelism, meaning that fewer 
operations are performed between 
points of synchronization. The ease of 
access to global memory also reduces 
initial setup time and allows different 
processes to be easily spawned or moved 
to another processor. In short, algo¬ 
rithms for shared memory are easier to 
design because of their flexibility, but 
shared-memory machines are more dif¬ 
ficult to program and debug because of 
the need to maintain data consistency. 3 

In contrast to shared-memory sys¬ 
tems, message-passing systems have lo¬ 
cal memory for each processor but no 
globally accessible memory. Processors 
must send messages across some inter¬ 
connection medium, also called a mes¬ 
sage fabric, to share data. It may take 
hundreds or even thousands of instruc¬ 
tions to package a message for trans¬ 
mission, so communication costs are 
much higher than for shared memory. 
Also, message transfer time depends on 
the distance, or the length of the com¬ 
munication channel, between commu¬ 


nicating processors. Message¬ 
passing systems use numer¬ 
ous interconnection strate¬ 
gies. Each involves trade-offs 
of distance between proces¬ 
sors and the number of con¬ 
nections per processor. 

Because communication 
time depends on distance, 
data location is often more 
critical in message-passing 
systems than in shared-mem¬ 
ory systems. Determination 
of which processors perform 
certain tasks is much more 
important in message-passing 
systems, too. Processes need¬ 
ing to communicate frequent¬ 
ly must be executed on pro¬ 
cessors that are . close 
together. Therefore, algo¬ 
rithms must be designed for 
the target machine’s specific 
communications topology. 
Algorithms designed for one machine 
may not perform satisfactorily on an¬ 
other. 3 Data must be explicitly moved 
from one processor to another using the 
send-and-receive mechanism. 

Synchronization between processors 
also depends on messages and is there¬ 
fore more time-consuming than in 
shared-memory systems. For this rea¬ 
son, algorithms for message-passing 
machines must use course-grained par¬ 
allelism, in which many instructions are 
processed between synchronization 
events. Setup time is much longer on 
message-passing systems because all of 
the program code and data, such as the 
circuit topology information, must be 
loaded across the message fabric. New 
processes are harder to spawn for the 
same reason, and this makes setting up 
one processor as a master more diffi¬ 
cult. Proper load balancing among the 
processors is also more difficult. In gen¬ 
eral, algorithms for message-passing 
systems are harder to design well, but 
the programs themselves are easier to 
implement and debug because data con¬ 
sistency is more easily maintained. 3 

One criteria for evaluating the quali¬ 
ty of a parallel solution to a problem is 
how well it scales. An algorithm scales 
well if the computation time decreases 
linearly, or nearly so, with an increase in 
the number of processors in the system. 
The speedup of a given parallel algo¬ 
rithm is defined as the ratio of the time 
taken by the fastest sequential algo¬ 
rithm running on an equivalent unipro- 
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cessor to the time taken by the parallel 
algorithm on the parallel machine. The 
goal is to have the algorithm’s speedup 
scale linearly with the number of pro¬ 
cessors. Speedup is given by 


where S is the speedup,/is the fraction 
of the code that must be executed se¬ 
quentially, and N is the number of pro¬ 
cessors. This function is plotted for/= 1 
percent and / = 5 percent in Figure 2. 
The figure shows that programs with a 
larger percentage of sequential code do 
not scale as well because the speedup 
decreases rapidly with increasing num¬ 
bers of processors. This phenomenon is 
called Amdahl’s law. Factors that can 
increase the amount of sequential code 
in an algorithm include many synchro¬ 
nization points or large setup require¬ 
ments. 

Fault partitioning 

Having discussed the major ATPG 
algorithms and the basic types of paral¬ 
lel computers, we can now look at the 
methods that have been used to paral¬ 
lelize ATPG. The most basic parallel¬ 
ization method is fault partitioning. 

The simplest way to parallelize the 
ATPG problem is to divide the fault list 
among the processors. Each processor 
then generates tests for each fault on its 
portion of the fault list until all tests 
have been generated. This scheme re¬ 
sults in each processor having a com¬ 
pletely separate task in that it performs 
the entire test generation procedure on 
its own. If the fault list is divided care¬ 
fully, each processor will have roughly 
the same amount of work and will finish 
in about the same time. In practice, 
optimal partitioning of the fault list is 
not easy to do a priori, so the scheduling 
can be done dynamically, with each pro¬ 
cessor requesting a new fault from a 
master scheduler whenever it is idle. 
Dynamic scheduling requires increased 
communications overhead because of 
requests from idle processors for new 
faults to process. The fault-partitioning 
method is especially suitable for mes¬ 
sage-passing systems because syn¬ 
chronization is necessary only when a 
new fault is needed from the remaining 
fault list. 

Patil and Banerjee 4 analyze a fault¬ 



processors. 


partitioning system used in conjunction 
with fault simulation. In this system, 
after a processor generates a test for a 
specific fault/, it performs fault simula¬ 
tion to determine what other faults this 
test vector covers. If another fault /■ is 
covered by the test vector, it must be 
removed from the fault list. If / has 
been assigned to another processor, a 
message must be sent to that processor 
instructing it to remove / from the fault 
list. This communication increases the 
parallel system’s overhead and reduces 
the possible speedup. 

To reduce this communication over¬ 
head, it is necessary to assign faults that 
are likely to be covered by the same test 
vector to the same processor. Like stat¬ 
ic scheduling, this division of the fault 
list is difficult to do a priori. If commu¬ 
nication of covered faults to other pro¬ 
cessors is removed completely, tests will 
be generated for faults that have al¬ 
ready been covered, and this redundan¬ 
cy will result in a larger test set. 

Patil and Banerjee present the results 
from several methods of partitioning 
faults across processors. These meth¬ 
ods include random partitioning, parti¬ 
tioning by input and output cones (dis¬ 
cussed in a later section), and mandatory 
constraint propagation. Mandatory con¬ 
straint propagation refers to grouping 
all faults with the same unique implica¬ 
tion values on certain circuit nodes into 
pseudocompatible fault sets. All faults 
within these sets are then assigned to 
the same processor. Mandatory con¬ 
straint propagation is more computa¬ 
tionally complex than the other three 
methods. The results of using these tech¬ 
niques to partition faults across proces¬ 
sors statically indicate that although 


processing by input/output cones or 
mandatory constraint propagation pro¬ 
duced smaller test sets, the load on the 
processors was unbalanced. This oc¬ 
curred because these partitioning meth¬ 
ods tended to assign related hard-to- 
detect faults (faults that caused many 
backtracks) to the same processor. 

To address this problem, Patil and 
Banerjee developed a combined static 
and dynamic load-balancing technique. 
Initially, faults are allocated to a pro¬ 
cessor using one of the methods dis¬ 
cussed previously. If a processor suc¬ 
ceeds in generating tests for all of the 
faults in its list, it requests work from 
the processor with the largest remain¬ 
ing fault list. This processor sends half 
of its list to the idle processor. This 
load-balancing scheme results in high 
message traffic only toward the end of 
the test generation process. Patil and 
Banerjee’s results on this combined tech¬ 
nique indicate that partitioning by in¬ 
put cones performed best and resulted 
in near linear speedup for up to 16 pro¬ 
cessors on the largest benchmark cir¬ 
cuits. 

Fujiwara and Inoue 5 developed an 
analytical method to calculate the opti¬ 
mal granularity and speedup ratio of a 
fault-partitioning system. In this case, 
optimal granularity refers to the size of 
the fault list allocated to each proces¬ 
sor. Consider a system of N processors 
with a mean processing time of x calc for 
each fault and an average communica¬ 
tion time of T comm . Also, assume a homo¬ 
geneous system — that is, the process¬ 
ing time for each fault is uniform for all 
processors, and the probability that a 
fault is allocated to a processor is 
equiprobable for all processors. For a 
circuit with a fault list of M faults, the 
authors derive the expression for the 
minimum total processing time as 


= MS- k*+ Tcoh 


This equation shows that the minimum 
processing time is achieved when each 
processor receives MIN faults to pro¬ 
cess and the fault list is communicated 
only once from the master processor. 

Fujiwara and Inoue then use this proof 
as a basis to extend the analysis to a 
system that performs fault simulation 
as well as test generation. The expres¬ 
sions developed for minimum process¬ 
ing time and speedup show a strong 
dependence on what the authors termed 
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“the ratio of newly processed faults to 
target faults — p.” When a processor 
finds a test for one of the faults on its 
fault list, it will then perform fault sim¬ 
ulation on the remaining faults on the 
list. As a result, pM faults will be found 
to be newly detectable or redundant. 
Thus, p is given by 

number of newly 
processed faults per processor 

p =- 

number of faults per processor 

Obviously, this ratio will decrease as 
the number of processed faults and the 
fault list decrease. Since p is a function 
of the number of processed faults x, 
p(x) can be expressed as 


where r 0 , r u and r 2 are constants and M p 
is the number of faults allocated to each 
processor. The term r ,x accounts for the 
decrease in p due to the decreasing 
number of faults left to process, and the 
term r 2 M p N accounts for the decrease in 
p due to the overlapped processing for 
faults that are simultaneously detected 
by different processors. 

Analysis of the expressions derived 
for total processing time and optimal 
granularity shows that as the factors r, 
and r 2 decrease, total processing time 
and optimal granularity also decrease. 
This occurs because as r x decreases, the 
number of faults detected by fault sim¬ 
ulation for each test pattern increases, 
and as r 2 decreases, the wasted process¬ 
ing due to overlapping faults decreases. 
The expressions for total processing time 
and optimal granularity also show that 
both quantities decrease as the system’s 
communication time decreases, as would 
be expected. 

Fujiwara and Inoue implemented a 
fault-partitioning system on a network 
of Sun workstations to obtain experi¬ 
mental results. These results showed 
that the analysis is valid even if it is 
slightly optimistic. The results obtained 
for optimal granularity and maximum 
speedup on the network of Suns showed 
the same trends as the analytical results, 
but the actual performance was less than 
predicted. 

One of the greatest disadvantages of 
fault partitioning is the long setup time 
for a message-passing system. The en¬ 
tire ATPG program and circuit data¬ 
base must be loaded into each proces¬ 


sor’s memory across the message fabric. 
If the total amount of work that can be 
divided among the processors is large 
(that is, if the fault list is long), then the 
percentage of time spent on setup can 
be kept small and this scheme has prom¬ 
ise. But if the circuit has a small number 
of faults, or fault classes, then the speed¬ 
up will be limited, as the previous anal¬ 
ysis suggests. In any case, because of the 
long setup time, this method does not 
scale well on smaller circuits. 

Moreover, the method also performs 
poorly if only a few hard-to-detect faults 
account for most of the processing time. 
Because processors cannot cooperate 
in generating a test for the same fault, 
one or two processors could take hours 
to generate a test for these hard-to- 
detect faults while the others stand idle. 
Many typical circuits have only a few 
hard-to-detect faults and thus fall into 
this category. Published results for sys¬ 
tems that use this technique show that 
linear speedup is possible only for a 
small number of processors, usually less 
than lO. 5,6 Clearly, this method of paral¬ 
lelization is less than optimum, although 
it is the simplest to implement. 

Heuristic 

parallelization 

As discussed earlier, heuristics are 
used to guide ATPG. Research has in¬ 
dicated that many heuristics will pro¬ 
duce a test for a given fault within some 
computation time limit when other heu¬ 
ristics have failed to do so. 2 These com¬ 
plementary heuristics can be used in a 
multiprocessor system to aid ATPG. 
Chandra and Patel reported the results 
from such a scheme. 6 They used two 
basic strategies: a variation of the fault¬ 
partitioning scheme discussed above, 
and concurrent parallel heuristics. 

In the variation of the fault-partition¬ 
ing method, which they call uniform 
partitioning, the fault list is divided 
among the processors and each gener¬ 
ates tests for the faults on its own por¬ 
tion of the list. In the attempt to gener¬ 
ate the tests, however, multiple heuristics 
are used in sequential order. If a heuris¬ 
tic fails to generate a test within a time 
limit, that heuristic is discontinued and 
the next one on the list is begun. This 
scheme has the same advantages and 
disadvantages as the fault-partitioning 
scheme discussed above. However, it is 


slightly better in some cases because 
the multiple heuristics shorten the test 
generation time for hard-to-detect faults. 
Chandra and Patel found that this strat¬ 
egy produces almost linear speedup for 
a system of five distributed-memory 
processors. 

In the concurrent parallel heuristic 
method, the system is required to have 
k x h processors, where h is the number 
of different heuristics available. If k 
equals 1, each processor computes a 
test for the same fault using one of the h 
heuristics. Whenever a processor suc¬ 
ceeds in generating a test for the fault, it 
sends a “stopwork” message to the oth¬ 
er processors in the cluster and they 
stop processing that fault. A new fault is 
selected from the fault list and the pro¬ 
cess begins again. If k is greater than 1, 
the processors are clustered into groups 
of h and each cluster works on a sepa¬ 
rate fault. In this case, the system is 
actually using a combination of the fault¬ 
partitioning and heuristic paralleliza¬ 
tion schemes. 

The concurrent parallel heuristic 
method has the potential to achieve 
greater speedups than the uniform-par¬ 
titioning method because of possible 
anomalies in the ordering of the heuris¬ 
tics for different faults. For example, 
suppose the time limit for each of five 
heuristics in the uniform-partitioning 
method is 10 seconds and only the last 
heuristic on the list can generate a test 
for a specific fault within the time limit, 
say in 5 seconds. Then the processing 
time for the uniform-partitioning meth¬ 
od will be 45 seconds. However, the 
concurrent heuristic method will find a 
test for this same fault in only 5 seconds. 

In the concurrent heuristic method, 
there is no way to ensure that the search 
space of each processor is disjoint. That 
is, even though the heuristics used by 
the processors differ, they might all lead 
the ATPG algorithm down the same 
path to a nonsolution and a test may not 
be found in the allotted time, even though 
one exists. The major drawback of the 
concurrent heuristic method is that for 
each fault, the work of the h-x proces¬ 
sors (where x is the number of heuristics 
the uniform method used to generate a 
test) is wasted. Also, in a message-pass¬ 
ing system, computation time is wasted 
while the “stopwork” message travels 
over the message fabric. 

For these reasons, Chandra and Patel 
found that for most benchmark circuits 
the concurrent heuristic method gener- 
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ally doesn’t perform as well as the uni- 
form-partitioning method. In some cas¬ 
es, the concurrent heuristic method, on 
a system of five distributed-memory 
processors, produced almost no speed¬ 
up over a uniprocessor system. This 
occurred in benchmark circuits with few 
or no hard-to-detect faults. In these cir¬ 
cuits, the uniform-partitioning method 
would generate tests for a majority of 
the faults using the first heuristic and 
not have to change heuristics, and the 
concurrent method would waste the 
work of all h - 1 processors. 

Search-space 

partitioning 

The main disadvantage of the heuris¬ 
tic techniques just discussed is that the 
processors cannot efficiently work to¬ 
gether to find a test for a single hard-to- 
detect fault. This disadvantage may be 
significant if the circuit contains a few 
hard-to-detect faults that take large 
amounts of computation time. Since this 
situation is not uncommon, we need 
some way to have the processors work 
cooperatively to find a test for a single 
fault. Search-space partitioning is such a 
method. 

One way to achieve cooperation 
among processors is to use the divide- 
and-conquer approach, dividing the pro¬ 
cess into smaller tasks that can be com¬ 
pleted in parallel. This concept is called 
algorithmic parallelization, also known 
as AND parallelism, and is discussed in 
the next section. 

Another way to parallelize work on a 
single fault is to divide the search space 
into disjoint pieces and evaluate them 
concurrently. This approach is a paral¬ 
lel implementation of the branch-and- 
bound method, which involves concur¬ 
rent evaluation of subproblems. This 
technique is called OR parallelism, and 
Patil and Banerjee have devised an 
adaptation of OR parallelism to the 
ATPG problem. 7 Their method is based 
on Podem because Podem orders the 
search space and allows it to be divided 
easily. 

The heuristics used in ATPG are not 
exact and may lead the algorithm down 
a search path that is a nonsolution, or at 
least not the shortest path to a solution. 
According to Patil and Banerjee, previ¬ 
ous research shows that increasing the 
backtrack limit in an algorithm with a 



particular heuristic does not necessarily 
result in increased performance. They 
believe this is because the assignment 
that caused the conflict, and hence the 
backtrack, is not necessarily the assign¬ 
ment that was just made. In other words, 
heuristics can order the search space 
such that the cause and effects of back¬ 
tracks are not close to each other in the 
search tree. To solve this problem, we 
would like to be able to tell, in every 
case, which input assignment led to a 
conflict, but in practice this is very diffi¬ 
cult. 

Another way to solve this problem is 
to divide the search space such that 
subproblems skipped by one processor 
are evaluated by another. The search 
spaces for the processors are therefore 
disjoint and are spread as far as possible 
across the solution space to maximize 
the area of the current search. This or¬ 
ganization increases the chances of find¬ 
ing a valid solution quickly. 

Figure 3 illustrates the process of di¬ 
viding a search tree. The search space 
belonging to processor X is divided into 
two parts for processors X and Y. Note 
that the processors are in fact always 
working on different problems (that is, 
disjoint search spaces) and that each 
processor will backtrack to a different 
place. If processor X finds a conflict, it 
backtracks and tries an alternate value 
for input A. Processor Y backtracks and 
tries an alternate value for input C in 
case of a conflict. This approach keeps 
the current search space as large as pos¬ 
sible, which tends to make the search 
more efficient. 

Patil and Banerjee 7 also discuss the 
implementation and results of their 
method using a 16-node Intel iPSC/2. 
The Intel iPSC/2 is a hypercube mes¬ 
sage-passing machine. A host processor 
acts as a gateway for the application to 
control the processing nodes. The pro¬ 


gram uses a dynamic scheduling system, 
with one of the processing nodes in the 
machine acting as a scheduler. The host 
sends the circuit description and the 
ATPG program to all other nodes. Pro¬ 
cessing begins when the host sends a 
message to the scheduler denoting the 
specific fault under test. The host then 
waits for a response from the scheduler, 
which in turn allocates the search space 
for the fault under test among the other 
processing nodes. It does this by initial¬ 
ly allocating the entire search space to 
one processor. The scheduler then sends 
a message to that processor requesting 
work. The processor divides its search 
tree as shown previously and sends one 
of the divisions back to the scheduler. 
The scheduler then sends this division 
of the search tree to an idle processor. 

This process continues until all pro¬ 
cessors are busy. If a processor searches 
its entire search tree and either doesn’t 
find a test or hits its backtrack limit, it 
stops work and sends a message to the 
scheduler that it is again idle. The sched¬ 
uler requests a portion of the search 
space from a busy processor and, upon 
receiving it, sends it to the idle proces¬ 
sor. 

If a processor succeeds in generating 
a test, it informs the scheduler that a test 
was found. The scheduler then stops 
work on all of the processing nodes and 
sends the test back to the host. The host 
sends a new fault to the scheduler, and 
the process begins again. If all of the 
processors signal the scheduler that they 
could not find a test in their search 
space within the backtrack limit, the 
scheduler sends an abort message to the 
host, indicating that a test could not be 
found. 

Patil and Banerjee 7 published results 
of their program on several benchmark 
circuits. They compared these results 
with those from a uniprocessor imple- 
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a search tree. 


mentation of Podem and made several 
major observations. 

First, increasing the backtrack limit 
on the uniprocessor implementation 
does not yield better results on hard-to- 
detect faults, and the parallel algorithm 
yields better results for an equal num¬ 
ber of backtracks. The results are better 
because the parallel algorithm searches 
a larger portion of the solution space, as 
mentioned earlier. Second, the parallel 
algorithm runs much faster than the 
uniprocessor implementation and ex¬ 
hibits nearly linear speedup in most cas¬ 
es for up to 16 processors. In one case, 
the parallel algorithm produced super- 
linear speedup, that is, speedup greater 
than the number of processors. Such 
speedup is sometimes possible in paral¬ 
lel branch-and-bound algorithms be¬ 
cause of anomalies in the search tree. 
The major problem with this approach 
is the long setup time required. The 
entire circuit database and ATPG pro¬ 
gram must be loaded into each proces¬ 
sor. On the other hand, processors are 
dedicated to only one task that does not 
change, and the tasks are completely 
independent. This makes the communi¬ 
cations overhead very low and results in 
greater efficiency. Search-space division 


is therefore most appropriate for cir¬ 
cuits that contain a small number of 
hard-to-detect faults that take up a great 
deal of computation time. It is also ide¬ 
ally suited to message-passing systems 
because of its course-grained parallel¬ 
ism. 

Motohara et al. also present a search- 
space-division method for hard-to-de- 
tect faults. 8 However, their representa¬ 
tion of the solution space as a search 
tree and their method for dividing it 
among the proces¬ 
sors is different. 
Instead of repre¬ 
senting the search 
space as a binary 
tree, they repre¬ 
sent it as a general 
m -ary tree in 
which each node 
can have an arbi¬ 
trary number of 
children. Figure 4 
shows an example 
of how a search 
tree for a circuit 
with five inputs 
might be divided. 
Each node in the 
search tree is still 
independent and can be processed as 
such, but the authors’ scheme does so in 
a breadth-first manner. 

Figure 5a shows how a uniprocessor 
implementation of a depth-first search 
would process the search tree. Figure 
5b shows how this same search tree 
would be processed in parallel using the 
method Motohara et al. present. Notice 
that nodes in the same level of the tree 
are handled by the same processor. This 
organization of the search tree results 
in extra work by a processor if an event- 
driven simulation process is done for 
the forward justification step. For ex¬ 
ample, suppose a processor has just per¬ 
formed justification for inputs A and B 
at the value 00 without finding a con¬ 
flict. In a depth-first search, an assign¬ 
ment would be made for input C, and 
only the events it causes would have to 
be computed. The work done to com¬ 
pute the circuit state for inputs A and B 
at 00 is saved. In the breadth-first search 
method, after A and B at 00 are found to 
be consistent, A and B at 01 are tried 
and the previous circuit state is lost. 
Also, breadth-first search is sometimes 
wasteful in that it searches almost the 
entire solution space before a test is 
found. In most cases, parallel depth- 



Figure 5. Sequential depth-first search (a); parallel 
breadth-first search (b). 


first search is more efficient in finding a 
solution. 

Motohara et al. have implemented 
their technique on a Links-1 multimi¬ 
croprocessor system. The Links-1 is a 
distributed-memory system using Z8000 
CPUs. The authors claim to have 
achieved, on average, linear speedup 
for up to 50 processors using the search- 
space-division method on several bench¬ 
mark circuits with up to 1,000 gates. 


Functional (algorithmic) 
partitioning 

Another method —functional parti¬ 
tioning — can be used to allow more 
than one processor to work simulta¬ 
neously on finding a test for a single 
fault. 

Functional partitioning refers to di¬ 
viding an algorithm into independent 
subtasks that can then be executed on 
separate processors in parallel. This 
method of parallelization is also known 
as algorithmic, or AND, parallelism. 
Most serial ATPG algorithms devel¬ 
oped thus far are difficult to parallelize 
functionally. The few subtasks that can 
be identified, such as fault sensitization 
and path sensitization, are not indepen¬ 
dent. That is, action taken to perform 
one of these processes may change the 
circuit state such that it has a side effect 
or causes an inconsistency in another 
process. Two goals cannot be justified 
simultaneously unless they consist of 
assigning values to two separate basis 
nodes. One way to allow parallelism in 
justification is to perform justification 
for goals in different faults simultaneous¬ 
ly. This is an adaptation of the fault¬ 
partitioning scheme already discussed. 

The Motohara system 8 uses a type of 
functional partitioning to remove the 
easy-to-detect faults from the fault list. 
This procedure is done before the par¬ 
allel method for hard-to-detect faults 
presented in the previous section is run. 
The method begins by dividing the fault 
list into groups of related faults. Typical 
related faults include those along the 
same path between a fault site and a 
primary output. After the fault list is 
divided into groups, each group is sent 
to a cluster of processors that includes a 
test generator and a fault simulator. 
The test generator takes the first fault 
and generates a test for it using a Podem 
algorithm with a limited number of back- 
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tracks. If a test for a fault is not generat¬ 
ed within the backtrack limit, it is con¬ 
sidered a hard-to-detect fault and is pro¬ 
cessed as such later. If a test is found, it 
is sent to a fault simulator node. This 
node runs a version of a concurrent 
fault simulator to determine which oth¬ 
er faults the test detects. These faults 
are then removed from the fault list. 

This technique reduces the size of 
both the remaining fault list to be pro¬ 
cessed by the ATPG algorithm and the 
test set itself. However, in some cases, 
performing fault simulation after algo¬ 
rithmic ATPG might not be very pro¬ 
ductive if the algorithmic ATPG is done 
carefully. For example, if the ATPG 
algorithm sensitizes a path for a stuck- 
at fault on a node to a primary output, 
every node in that path is also tested for 
a stuck-at fault. If the ATPG algorithm 
keeps a list of these incidentally tested 
faults and removes them from the fault 
list, fault simulation may not be produc¬ 
tive enough to warrant the additional 
computation time it entails. 

The Lover (logic verification) system 
that Ma et al. 9 describe uses a function¬ 
al-partitioning approach. Logic verifi¬ 
cation is a different problem from ATPG, 
with different objectives and different 
constraints. However, some of the steps 
required are similar, so a discussion of 
this system is instructive. The problem 
in logic verification is to determine 
whether two descriptions, A and B, of 
the same circuit are functionally equiv¬ 
alent. This is verified by taking the orig¬ 
inal description of the circuit A and 
enumerating all input combinations that 
cause a 1 to appear on a specific output 
of the circuit. This set of input vectors is 
called the On set of that output. The On 
set is then simulated on the new circuit 
description B to ensure that it produces 
a 1 on the output for every member of 
the set. This process is repeated for the 
Off set, which obviously is all input pat¬ 
terns that produce a 0 on the output. If 
the On sets and Off sets of all outputs 
for both descriptions are the same, the 
circuit descriptions are functionally 
equivalent. 

Determining the On and Off sets for 
each output involves an enumeration 
operation that is very similar to the 
Podem justification operation. The 
main difference is that in logic verifica¬ 
tion the entire solution space must be 
implicitly searched because every 
member of the On and Off sets must 
be found. 


There are two opportunities for par¬ 
allelism here. First, finding the On- and 
Off-set members for circuit description 
A and simulating them on circuit de¬ 
scription B can take place in parallel, 
similar to test generation and fault sim¬ 
ulation in the Motohara system. Sec¬ 
ond, the enumeration process can be 
parallelized using the search-space-di- 
vision method presented earlier. What 
is novel about the Lover system is that it 
includes a dynamic scheduling scheme 
that switches between these methods as 
necessary to keep all processors busy. 
Ma et al. include a detailed discussion, 
but we will present an adaptation of it to 
the ATPG problem. The only changes 
made were to substitute test pattern 
generation and fault simulation for On- 
and Off-set enumeration and simula- 

Suppose we have divided the fault list 
and assigned a section to a cluster of 
processors, as in the Motohara system. 
The test generator processors in the 
cluster take faults from the list and per¬ 
form algorithmic ATPG on them. When 
a test is found, it is passed to a fault 
simulator processor, which performs 
fault simulation with it. If the faults 
being processed are easy-to-detect faults, 
the number of processors doing ATPG 
and fault simulation will be roughly 
equal. If an ATPG processor then runs 
into a hard-to-detect fault and begins to 
backtrack a lot, the number of tests 
being generated will decrease and the 
fault simulator processors will begin to 
idle. If the system stops ATPG on the 
hard-to-detect fault after a certain num¬ 
ber of backtracks, the work that was 
done thus far in searching the solution 
space will be wasted. 

A better solution is to take an idle 
fault simulator processor and put it to 
work generating a test for the hard-to- 
detect fault using search-space division. 
This method keeps the processors busy 
and minimizes wasted processing. The 
disadvantage of this method is that a 
processor has to know how to do two 
tasks, fault simulation and parallel 
ATPG. If the system is a message-pass¬ 
ing system and each processing node 
does not have enough memory to store 
the necessary circuit database and the 
program code for the two tasks, this 
method may not be effective. This inef¬ 
fectiveness results because the differ¬ 
ent program code will have to be loaded 
across the message fabric whenever a 
processor switches tasks, and task switch 


time will be large. If the system is a 
shared-memory machine, where code is 
stored in a global memory, or a mes¬ 
sage-passing system, where each node 
has adequate memory to store both pro¬ 
grams, task switch time will be quite 
small and this technique could be effec¬ 
tive. 

Topological 

partitioning 

In all of the parallel algorithms dis¬ 
cussed so far, each processor must have 
access to the entire circuit database. 
This may be a problem for large circuits 
because each processor may not have 
enough memory to hold the entire cir¬ 
cuit database. Also, loading the data¬ 
base into memory in a message-passing 
system takes time. Topological parti¬ 
tioning of the circuit into separate par¬ 
titions and instantiating each on a dif¬ 
ferent processor would help alleviate 
this problem. The Lover system uses a 
type of circuit partitioning. Recall that 
a group of processors works on enumer¬ 
ating and simulating the On and Off 
sets for a particular output. That group 
of processors needs the database for 
only the portion of the circuit that af¬ 
fects that output. This portion of the 
circuit is called a fan-out cone, and it is 
constructed by backtracing from the 
output along every path to a primary 
input. Every gate in all backtrace paths 
is included in the fan-out cone. This 
process results in some gates being in 
more than one fan-out cone, but this is 
acceptable in logic verification. This sit¬ 
uation is not acceptable in ATPG, so 
some method must be used to place 
such gates in one group or another. 

Researchers have been investigating 
topological partitioning for parallel logic 
simulation for some time. Hirose et al. 10 
present results of using a parallel logic 
simulator to generate tests for combi¬ 
national logic circuits. The machine used 
is the special-purpose simulation pro¬ 
cessor developed by Fujitsu Ltd. In this 
system, the circuit is divided topologi¬ 
cally among several processors, called 
gate processors, in preparation for fault 
simulation. Faults are injected into the 
circuit and then a depth-first search sim¬ 
ilar to that of Podem searches the entire 
input space to find an input that detects 
the injected faults. The major disadvan¬ 
tage of this system is that it has been 
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Table 1. Summary of results. 


System 

Methods 

Used 

Parallel 

Machine 

Scalability 

Major 

Results 

Srinivas Patil 

Prith Banerjee 4 

Fault 

partitioning 

Algorithmic 

partitioning 

Intel iPSC/2 

Nearly linear speedup for up to 

8 processors; speedup falls off 
after that. 

Demonstrated that ATPG with 
fault simulation is more efficient 
than ATPG alone, even in 
parallel environment. Fault 
partitioning shows good 
speedup for up to 8 processors. 

Hideo Fujiwara 
Tomoo Inoue 5 

Fault 

partitioning 

Network of 
Sun 3/50 
workstations 

Nearly linear speedup for up to 

5 processors. 

Verified analysis of optimal 
grain size for fault-partitioning 
system with experimental 
results. 

Susheel J. Chandra 
Janak H. Patel 6 

Fault 

partitioning 

Heuristic 

parallelization 

Network of 
Sun 3/50 
workstations 

Uniform partitioning: nearly 
linear speedup for 5 processors. 

Concurrent heuristics: less than 
linear speedup for only 5 
processors. 

Introduced concept of heuristic 
parallelization and developed 
two methods: uniform and 
concurrent heuristics. 
Demonstrated uniform 
partitioning produces better 
speedup. 

Srinivas Patil 

Prith Banerjee 7 

Search-space 

partitioning 

Intel iPSC/2 

Linear speedup for up to 16 
processors. Superlinear speedup 
in some cases. 

Introduced efficient search- 
space partitioning using Podem 
algorithm. 

Akira Motohara 
Kenji Nishimura 
Hideo Fujiwara 

Isao Shirakawa 8 

Algorithmic 

partitioning 

Search-space 

partitioning 

Links-1 

ZSOOO-based 

system 

Linear speedup for up to 10 
processors during algorithmic 
phase. 

Averaged linear speedup for up 
to 50 processors during search- 
space phase. 

Introduced combination of 
algorithmic- and search-space¬ 
partitioning systems. 
Demonstrated good speedup is 
possible for large numbers of 
processors using search-space 
partitioning. 

Fumiyasu Hirose 
Koichiro Takayama 
Nobuaki Kamato 10 

Topological 

partitioning 

Special- 

purpose 

simulation 

processor 

No results available. 

Demonstrated topological 
partitioning for simulation 
portion of ATPG process. 

Glenn A. Kramer 12 

Topological 

partitioning 

Connection 

Machine 

Linear speedup for circuits with 
up to 15-18 inputs. Speedup 
falls off rapidly after that. 

Employs topological 
partitioning by mapping one 
circuit element to each 

Connection Machine processor. 
Only current algorithm 
demonstrated on massively 
parallel machine. 


tailored to one specific special-purpose 
machine and is not suited to the many 
general-purpose multiprocessors that 
are readily available. 

A paper by Smith et al. 11 includes a 
discussion of circuit partitioning for 
parallel logic simulation on general- 
purpose multiprocessors. The objective 


of the partitioning scheme is to reduce 
the necessary communication between 
partitions as much as possible while 
maximizing the amount of work that 
can be done concurrently within the 
partitions. The authors analyze six dif¬ 
ferent partitioning schemes: random 
partitioning, natural partitioning, parti¬ 


tioning by gate level, partitioning by 
element strings, and partitioning by fan- 
in and fan-out cones. 

Natural partitioning consists of divid¬ 
ing gates into groups according to their 
position in the gate list. This method is 
only slightly more ordered than random 
partitioning. Partitioning by gate level 
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refers to assigning gates to groups ac¬ 
cording to their level in the circuit, that 
is, their distance from the primary in¬ 
puts. Partitioning elements by strings 
refers to grouping sets of connected 
gates that include at most one fan-in or 
fan-out connection. Partitioning by fan¬ 
out cones is done as in the Lover system 
except that when gates are connected to 
more than one fan-out cone, they are 
assigned to the one they are more high¬ 
ly connected to. Fan-in cones are found 
in the same manner except that the pro¬ 
cess begins at each primary input. 

The results presented by Smith et al. 
indicate that for simulation, random 
partitioning scores best in concurrency 
but worst in interprocessor communi¬ 
cation. This condition would make ran¬ 
dom partitioning a bad choice for most 
systems. Partitioning by fan-in and fan¬ 
out cones offers the best trade-off be¬ 
tween concurrency and interprocessor 
communication, with fan-out cones be¬ 
ing slightly better. This is probably be¬ 
cause fan-out cones closely fit the flow 
of activity in the circuit during logic 
simulation. 

It appears that the optimum parti¬ 
tioning method for ATPG will depend 
on the algorithm used. Podem uses a 
simulation-like process for justification, 
and partitioning by fan-out cones may 
be best. However, circuit activity in the 
D-algorithm tends to be along circuit 
levels, as during the advance of the D 
frontier (see sidebar). Using the D- 
algorithm, partitioning by gate levels 
may produce better results. In any case, 
the circuit must be partitioned carefully 
to reduce the communication required 
between the partitions. If the circuit is 
partitioned incorrectly, the algorithm 
becomes communication bound and the 
computation time is dominated by the 
interprocessor communication time. The 
topological-partitioning approach would 
seem to be better suited to shared-mem¬ 
ory machines with their inherently low¬ 
er communication times. 

The only system we are aware of that 
uses circuit partitioning to parallelize a 
serial ATPG algorithm is the one under 
development at the University of Vir¬ 
ginia. The system begins by assigning 
gates to any one of N partitions accord¬ 
ing to some heuristic. Here, N is the 
number of processors in the system. An 
attempt is made to optimize this parti¬ 
tioning by perturbing the solution and 
minimizing some cost function. This 
method is a multivariate optimization 


problem that is itself NP complete. The 
quality of the solution reached depends 
on the quality of the initial solution 
produced by the heuristic. Also, mea¬ 
surement of the cost function used in 
the minimization is an issue. As stated 
previously, it is not known at this time 
what constitutes optimum partitioning 
for ATPG algorithms. Further research 
in this area is needed. 

Another issue in circuit partitioning 
for ATPG is the number of gates in each 
partition — the so-called block size. As 
the number of gates assigned to a block 
decreases, the amount of work that can 
be done between communication steps 
becomes smaller. Hence, the parallel¬ 
ism becomes finer and finer grained. In 
message-passing systems, the minimum 
block size for efficient operation could 
be quite large because of the greater 
communication costs. On a shared-mem¬ 
ory machine, the minimum block size 
could be smaller. The minimum block 
size will also affect how the problem 
scales as the number of processors in¬ 
creases. As more processors are added 
to the system, the block size will get 
smaller and efficiency will decrease. 

Kramer presents a system based on 
circuit partitioning for the Connection 
Machine. 12 This system goes to the ex¬ 
treme of instantiating each gate on a 
single Connection Machine processor 
or a group of processors. This approach 
is viable only because the Connection 
Machine has very fast interprocessor 
communication and the algorithm used 
finds tests for all of the faults in the 
circuit simultaneously. Even so, the au¬ 
thor admits that the algorithm is com¬ 
munication bound. His approach is tai¬ 
lored specifically for the Connection 
Machine and also has the disadvantage 
that runtime increases exponentially for 
circuits with more than 15-18 inputs. 
This limitation makes it unsuitable for 
most practical circuits. 


A lgorithmic ATPG for combina¬ 
tional circuits is an active area 
of research in test generation 
for digital systems. Application of par¬ 
allel processors to this problem has 
shown some promising results, but much 
work remains. Each method of parallel¬ 
ization presented in this article has some 
drawbacks. Table 1 summarizes the re¬ 
sults obtained by each of the systems we 
reviewed. As the summary shows, ex¬ 
cept for search-space partitioning, no 


technique has demonstrated the capac¬ 
ity to produce linear speedup for more 
than 16 processors. 

Search-space partitioning shows the 
most promise for scalability to large 
numbers of processors. However, it does 
not answer the problem of large circuit 
databases created by increasing VLSI 
circuit sizes. Also, this technique is ap¬ 
plicable only to hard-to-detect faults 
and does not address acceleration of the 
ATPG problem for easy-to-detect faults, 
which constitute the majority of the fault 
list for most practical circuits. Clearly, a 
combination of techniques or an alto¬ 
gether new ATPG algorithm designed 
for parallel processors will have to be 
developed to utilize the massively par¬ 
allel machines with hundreds or thou¬ 
sands of processors that will be avail¬ 
able in the future. ■ 
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SPECIAL REPORT 



High-performance computing is ‘window 
into future,’ says President’s science advisor 


Ware Myers, Contributing Editor 


H igh-performance comput¬ 
ing will remain the cen¬ 
terpiece of the administration’s 
efforts in science and technology,” said 
D. Allan Bromley, assistant to Presi¬ 
dent George Bush for science and tech¬ 
nology and director of the US Office of 
Science and Technology Policy. Brom¬ 
ley delivered the keynote address to an 
audience of several thousand on the 
opening day of Supercomputing 91. The 
conference was held in Albuquerque, 
New Mexico, November 19-22 follow¬ 
ing a day of tutorials. The IEEE Com¬ 
puter Society and ACM cosponsored 
the fourth annual event, with Raymond 
L. Elliott of Los Alamos National Lab¬ 
oratory serving as general chair. 

In the High-Performance Computing 
and Communications Initiative, both 
Congress and the President have recog¬ 
nized the fundamental importance of 
the field. That recognition takes the 
form of a 30-percent increase in funding 
to $638 million this year. The adminis¬ 
tration has recommended to Congress 
an increase from last year of 100 per¬ 
cent over a five-year period, ultimately 
reaching more than $1 billion a year. 

“I believe that this is probably the 
most important single initiative that we 
in the federal government can take, 
measured in terms of its potential im¬ 
pact on our society and citizens,” Brom¬ 
ley asserted. “It is our window into the 
future of the information age.” 

What the initiative contains. The ini¬ 
tiative encompasses four elements: 

• the computing systems themselves, 
• the advanced software technology 
and algorithms that make it possi¬ 
ble to use the hardware, 

• the National Research and Educa¬ 
tion Network (NREN) that makes 
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this power broadly available, and 

• the development of the necessary 
human resources and basic research 

“Our goal has been to obtain hard¬ 
ware capable of computing at the tera- 
flops level,” Bromley said of the first 
element. That is 1 million megaflops. At 
the time Bromley was developing plans 
for the initiative, he did not believe that 
level would be available until at least 
the end of 1993. Several manufacturers 
have indicated recently that “if we can 
come up with the money, they can come 
up with the hardware before the end of 
1992.” Then, eliciting a burst of laugh¬ 
ter, he added, “I am not sure which is 
the greater challenge.” 

In a press conference, Bromley point¬ 
ed out that his office does not buy super¬ 
computers. Program offices with big 
computation problems do that. They 
are the units of the federal government 
that will have to justify a teraflops com¬ 
puter in terms of its value in solving 
their problems. 

With regard to the second element, 
the people who develop the software 
for both traditional supercomputers and 
the newer massively parallel machines 
tend to be computer mavens. “They 
tend to work in advanced aerodynam¬ 
ics, nuclear weapons, and other fields 
where what one can say of the software 
is that it is not user friendly,” Bromley 
observed. “Until we can get user-friendly 
software, the great majority of our pub¬ 
lic is simply not going to make the ef¬ 
fort. That is one of the fundamental 
challenges.” 

The third element, once you have the 
hardware and software, is the high-per¬ 
formance network that makes this ca¬ 
pability accessible to large industries 
and small, to schools, and in some cases 
to individual homes. There has been 
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confusion about NREN. “It is not in¬ 
tended to be the national network,” 
Bromley said. “The government will not 
own it.” 

NREN is designed to be a testbed for 
networking. It will explore new proto¬ 
cols, procedures, and designs. It will use 
fibers already owned and in place by the 
major trunk carriers. 

“It is our hope that the private sector 
will take up the challenge to develop 
this network,” Bromley continued. “We 
hopethatbytheendofthe nineties it will 
be as ubiquitous, as familiar, and as reg¬ 
ularly used as is the telephone today.” 

For this evolution to take place, the 
network must be transparent. “All the 
users of this network will care about is 
getting the solution to their problem 
back in their hands as quickly and eco¬ 
nomically as possible,” he said. 

If the first three elements are going to 
work out, we are going to need many 
more trained people, both at the pro¬ 
fession level and the technician level, 
Bromley pointed out. Technicians — 
even supertechnicians — will not only 
keep these systems running, they will 
also make small evolutionary improve¬ 
ments that will make the systems work 
better, more cheaply, and more efficiently. 

“We will be short some millions of 
technicians by the end of this decade,” 
Bromley noted. “The federal govern¬ 
ment spends only 2.8 percent of its sup¬ 
port on the two-year colleges that pro¬ 
duce most of the technicians. That is a 
situation that is under review. Clearly it 
is one that needs correction.” 

Need for supercomputers. Supercom¬ 
puters are just beginning to be able to 
model the kind of chemistry that goes 
on in the atmosphere. “Up to now, mod¬ 
els of global warming and the green¬ 
house effect have focused on first-order 
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effects,” Bromley said. By first-order 
effects, he means the initial set of chem¬ 
ical reactions. “Now that we are able to 
do supercomputer modeling, we can look 
at second-, third-, and fourth-order 
chemical processes. We already have an 
indication that they are going to be very 
important.” 

That is one reason we need vastly 
better computational power. “We need 
it to understand enough about these 
complex atmospheric problems to be 
able to make policy decisions that make 
sense,” he said. Bromley said he doesn’t 
want to make decisions that require bil¬ 
lions of dollars of expenditure without 
fully understanding what he is recom¬ 
mending. 

“When the Mission to Planet Earth 
[project] sends up the Earth-Observing 
System A, it will send back every 4.8 
days information equivalent to the en¬ 
tire contents of the Library of Con¬ 
gress,” Bromley said, giving another 
example of the need for supercomputers. 
“Unless we have a factor of 100 to 1,000 
in computer speed and capacity and 
similar factors for data transmission 
rates, we will simply be swamped — 
unable to analyze the data and unable 
to get the information we need to make 
policy decisions in any reasonable time.” 

Massively parallel computers. Alli- 
ant Computer Systems introduced the 
Campus/800 during the conference; the 
800 in the model name refers to the 800 
reduced instruction-set computer pro¬ 
cessors in the product. It is the first 
system, the company said, to support 
both distributed and shared memory, 
making it easier to program and more 
efficient for real-world applications. 

Convex Computer introduced the 
C3400-ES entry-level system for depart¬ 
mental use. It has either one or two 
processors and reaches 200 megaflops 
peak. 

Digital Equipment announced the 
DECmpp 12000 system series last Au¬ 
gust. In effect, it is a DEC interface to a 
MasPar supercomputer. 

IBM announced a development ca¬ 
pability called the Integrated Parallel 
Accelerator (Inpac) in two configura¬ 
tions: 

• a 16-node facility that includes an 
integral ES/9000, and 

• a 60-node implementation that in¬ 
corporates select ES/9000 and ESI 
3090 processors. 


Inpac is one of several approaches that 
IBM is pursuing in parallel processing, 
the company said. 

Intel introduced the Paragon XP/S 
series in configurations ranging from 5 
to 300 gigaflops. The series is believed 
to be scalable to the teraflops level, but 
the price might be on the order of $200 
million with present technology. As chip 
capability rockets upward, this price will 
drop. “We are confident we can pro¬ 
duce teraflops systems that are both 
usable and affordable by the middle of 
this decade,” said Wendy Vittori, direc¬ 
tor of marketing and strategic planning 
at Intel’s Supercomputer Systems Divi- 

Thinking Machines announced its 
Connection Machine model CM-5 in 
October. Its architecture is also scal¬ 
able to the teraflops level. 

Wavetracer announced Zephyr, which 
it termed the world’s first deskside mas¬ 
sively parallel computing system. Zeph¬ 
yr’s two models do contain 4,096 and 
8,192 simple processing elements re¬ 
spectively, and it is relatively low in 
cost, as supercomputers go. However, 
at present only two applications have 
been programmed. 

Parallel vector system. Cray Research 
unveiled the Cray Y-MP/C90 parallel 
vector system at both this conference 
and in Tokyo. The system features an 
all-new CPU with a peak performance 
of 1 gigaflops. Containing 16 of these 
CPUs, the system’s peak performance 
is 16 Gflops. 

A dual-vector pipeline allows each 
CPU to deliver two vector results per 
functional unit every clock period, said 
Les Davis, chief technical officer. This 
rate is four times that of Cray’s previous 
top-end system. 

Significantly, the new system is bina¬ 
ry-compatible with previous products 
in the Cray Y-MP line. In other words, 
it accepts existing machine code; source 
code does not have to be recompiled. 
Thus, the Cray library of more than 
1,000 application codes is immediately 
useful. 

Dynamic dataflow computer. The 

Monsoon dynamic dataflow computer 
is the outcome of more than 10 years’ 
research in this architecture and an en¬ 
abling language by the Computation 
Structures Group within the MIT Lab¬ 
oratory for Computer Science. In 
August 1991, Motorola delivered the 


first prototype to MIT. At this confer¬ 
ence Motorola announced the delivery 
of a two-node unit to Los Alamos Na¬ 
tional Laboratory. It has scheduled a 
16-node unit for Los Alamos in the sec¬ 
ond quarter of 1992. 

The Computation Structures Group 
at MIT designed and implemented the 
Id parallel programming language, com¬ 
piler, and runtime system for Monsoon. 
The dataflow approach facilitates pro¬ 
grammability. This language allows the 
compiler to automatically expose the 
parallelism in an algorithm. 

Los Alamos plans to use its two-node 
Monsoon to develop a prototype of its 
existing Monte Carlo Neutron Photon¬ 
ics transport code in Id. The current 
code, running on a Cray machine, simu¬ 
lates experiments in nuclear safety. It is 
also used in a wide range of particle 
physics applications, including medical 
dosimetry simulations. In a petroleum 
application, it determines seismic struc¬ 
tures. 

Mass storage. With the computers 
themselves capable of greatly increased 
performance, and with gigabit networks 
coming, a third need is mass storage. In 
an interview, Ann Hayes, the confer¬ 
ence's deputy program chair who works 
at Los Alamos National Laboratory, 
said we need very dense and compact 
storage devices with very little latency. 
For instance, LANL has users who want 
to store 10 to 15 Gbytes that they can’t 
accommodate because they don’t have 
enough storage capacity. 

E-Systems has a product for commer¬ 
cial and government users who have 
data in terabyte quantities: EMASS (E- 
Systems Modular Automated Storage 
System). It consists of a file-server pro¬ 
cessor, magnetic disks, robotically ser¬ 
viced magnetic tape recorders, a con¬ 
trol console, and software. 

A modified video recorder, designat¬ 
ed the ER90, uses commercially avail¬ 
able small, medium, and large D2 cas¬ 
settes providing 25,75, and 165 Gbytes 
of storage, respectively. Its largest sys¬ 
tem stores 325 terabytes, and advanced 
systems ranging up to 10,000 terabytes 
are in development. 

E-Systems has been providing mass 
storage systems to government entities 
for more than 10 years and is transfer¬ 
ring this technology to the commercial 
arena. Early this year, it will deliver its 
first commercial system to Mobil Ex¬ 
ploration and Producing Services. 
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Gigabit network links supercomputers 

The Supercomputing 91 program committee installed a 1-gigabit network on 
the floor of the exhibit hall of the Albuquerque Convention Center for the dura¬ 
tion of the conference. The effort was led by Bill Boas of UltraNetwork Technolo¬ 
gies and Michael C. MacCracken of Lawrence Livermore National Laboratory. 
The network connected products provided by Cray Research, IBM, Thinking Ma¬ 
chines, Convex, Alliant, Maximum Strategy, and Silicon Graphics. 

“SCinet is the largest gigabit network in terms of the number of nodes assem¬ 
bled,” Ken Kennedy, program chair, said. “It is a demonstration of what can be 
done.” 

“The purpose of the demonstration was to let the research community use the 
application programs and data that they work with every day at home here on 
the exhibit floor,” Boas said. “SCinet is connected to the National Science Foun¬ 
dation-funded Internet — essentially to the rest of the world.” 

Some of the exhibitors are doing their computations back home, getting their 
results over the network, and showing them here, Boas continued. Others are 
pulling in their data from their home computers and doing their computations 
here. 

Bruce Shriver, 1992 president of the IEEE Computer Society, said the network 
“demonstrated that interoperability is a reality, not a myth. Putting it together in 
such a short time — four and a half days — was a significant technical accom¬ 
plishment.” 

Connections within the convention center used Hippi, FDDI, and Ethernet — 
all ANSI standards — at 1,000, 100, and 10 Mbps, respectively. The connections 
were provided by Network Systems, UltraNetwork Technologies, Synoptics Com¬ 
munications, Broadband Communications, and Aquila Technologies. JWP Net¬ 
work Services, Siecor, and Interop provided fiber and cable within the conven¬ 
tion center. Advanced Network Services, Cray Research, IBM, and Digital 
Equipment supplied network management and display stations. 

US West supplied the fiber line at 1,000 Mbps to connect the exhibit hall to 
Sandia National Laboratories and Phillips Laboratory at Kirtland Air Force Base, 
both in Albuquerque. Los Alamos National Laboratory, farther away, was served 
by a T3 fiber connection at 45 Mbps. US West, MCI, and Advanced Network and 
Services provided a 45-Mbps link to Internet. 

SCinet demonstrates some of the uses envisioned for the proposed National 
Research and Education Network. “We are showing the concept of NREN in an 
embryonic local form,” Boas explained. “These are the kinds of applications that 
people feel NREN will promote. 

“That is not to say that we have the equipment here that NREN will need,” 
Boas added. “There are probably several evolutions of software and hardware 
from what we have here to the capability envisaged for NREN. SCinet is a start¬ 
ing point. It employs the highest performance commercially available equipment 
that we could get our hands on today.” 

Boas’s group consisted of people from industry, the academic community, and 
government laboratories. “These are the three communities that the President’s 
High-Performance Computing and Communications program plans to pull to¬ 
gether,” Boas went on. “The people involved in SCinet have enjoyed the effort. It 
has been a tremendous learning experience. In a small way, we have also dem¬ 
onstrated the cooperation needed to build and utilize a 1 -gigabit network over a 
larger area.” — Ware Myers 


Convex announced three new file- 
server support products: 

• a helical tape interface, 

• a high-capacity disk drive, and 

• a virtual volume manager. 

The high-speed, helical-scan 19-mm Dig¬ 
ital Data-2 (DD2) tape subsystem records 
from 25 to 165 Gbytes per cassette. 

“Helical scan offers much higher re¬ 
cording densities than the 3,480-tape 
standard or nine-track tape,” said James 
A. Balthazar, Convex marketing vice 
president. “DD2 is rapidly becoming an 
accepted medium used to solve large- 
scale supercomputer storage problems. 
Up to 32 DD2 tape subsystems, avail¬ 
able through Ampex Data Systems and 
E-Systems, can be attached to one Con¬ 
vex integrated tape channel.” 

The new disk drives are 50 percent 
faster and provide 2.5 times more stor¬ 
age capacity than previous Convex disk 
offerings. 

The virtual volume manager allows a 
disk subsystem to tolerate failures of 
disk drives without the loss of data. 
Data redundancy is added to the disk 
stripe and subsystem through methods 
commonly known as RAID (redundant 
array of inexpensive disks) techniques. 
With this product, users have three choic¬ 
es in data protection: 

• mirroring, 

• redundant striping, and 

• hot-spares option. 

Maximum Strategy has been shipping 
RAID storage products since 1987. Its 
six series range in capacity from 3.2 to 
345 Gbytes. They connect to most of the 
supercomputers and workstations 
through Hippi, VME-2, and MicroChan¬ 
nel connections. 

Trend toward private sector. “The 
sale of supercomputers to the private 
sector was one of the trends we wanted 
to emphasize at this conference,” Ken 
Kennedy of Rice University, program 
chair, said in an interview. “The pro¬ 
gram committee tried to get a sense of 
what was happening and expose it in the 
meetings.” 

To this end, November 20 could have 
been called biology day, and November 
21, industry day — although there were 
other tracks as well. The 20th started 
with an invited lecture on the computa¬ 
tional dynamics of the cerebral cortex 


by Robert Wyatt of the Institute for 
Theoretical Chemistry, University of 
Texas at Austin. It continued with a 
“minisymposium” on medicine and bi¬ 
ology, dental biomaterials, patterns in 
the spread of cancer, and computation¬ 
al gerontology. The subject extended into 
the afternoon with a second minisympo¬ 
sium on molecular visualization, mo¬ 
lecular biology, and biological imaging. 


The morning minisymposium on the 
21st dealt with the petroleum industry: 
exploration geophysics and reservoir 
simulation. The luncheon speaker, Fred 
Hausheer of the Institute for Drug De¬ 
velopment, San Antonio, Texas, de¬ 
scribed the role that numerical simula¬ 
tion plays in studies of DNA-targeted 
drugs for use in treating cancer and 
AIDS. The afternoon panel discussed 
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the use of supercomputing in the finan¬ 
cial world, specifically at Prudential 
Securities, Citibank, and Dow Jones. A 
late afternoon minisymposium was de¬ 
voted to climate modeling. 

On the exhibit floor, booth people 
confirmed the trend. On the one hand, 
there is the expected decline in defense 
spending, driving vendors to the private 
sector. On the other hand, there is the 
rather small size of the massively paral¬ 
lel computer market. The Smaby Group 
estimated it to be $270 million per year, 
although growing at a rate of 40 percent 
per year. That market has to support a 
number of manufacturers, extensive de¬ 
velopment of better parallel software, 
and missionary work beyond the exist¬ 
ing application areas. To finance all this 
activity, it is imperative to expand the 
market. 

Alliant Computer Systems, for in¬ 
stance, lists applications in structural 
analysis, computational fluid dynamics, 
computational chemistry, graphics and 
imaging, and signal and seismic pro¬ 
cessing. 

Convex Computer has sold 950 sys¬ 
tems in 40 countries. Industrial cus¬ 
tomers are Ford, Texas Instruments, 
Nissan, 3M, Saab-Scania AB, Mobil, 
Dow Jones, Sony, Bayer AG, and many 
more. 

Cray Research systems have hitherto 
been rather expensive and consequent¬ 
ly have found most of their industrial 
applications in large technical indus¬ 
tries, such as automotive, aerospace, 
petroleum, chemical, nuclear energy, 
and electronics. However, this past year, 
Cray introduced an entry-level system 
that will no doubt extend its reach to 
smaller industries. 

Recent applications of Cray super¬ 
computers include 

• database management operational 
systems, 

•artificial intelligence applications, 
and 

• linear programming for scheduling 
and optimization. 

An application still under development 
is the optimization of processing-plant 
operations. Many processing plants still 
operate under analog setpoint control. 
Others have substituted digital comput¬ 
er control. A still more advanced tech¬ 
nique is to use a supercomputer to re¬ 
compute plant operating points as the 
mix of input materials varies, as opera¬ 


tional variables change, and as the val¬ 
ue of several outputs fluctuates. 

A user of Intel supercomputers since 
1989, Prudential Securities plans to up¬ 
grade from its current iPSC/860 to a 
Paragon XP/S. Prudential has already 
obtained a competitive advantage in a 
broad range of applications, according 
to David Audley, director, Prudential 
Financial Strategies Group. Most users 
of supercomputers in this field have 
kept the exact nature of their applica¬ 
tions proprietary for competitive rea¬ 
sons, but Audley described one of Pru¬ 
dential’s applications — collateralized 
mortgage obligations — at the panel on 
supercomputing in the financial world. 

Collateralized mortgage-backed ob¬ 
ligations are “engineered” bundles of 
mortgages traded on the secondary 
market. Bundles are fashioned to meet 
the needs of each buyer. Formerly, fig¬ 
uring out the yield, maturity date, etc., 
on a minicomputer took several min¬ 
utes, longer than a customer was willing 
to wait on the telephone. The iPSC/860 
makes this computation in less than 30 
seconds, while the customer remains on 
the phone. The more powerful Paragon 
XP/S will further reduce this delay. 

Prudential’s installation works 24 
hours a day, following the markets 
around the world. Trading is always in 
progress somewhere. 

Apparently, the use of supercom¬ 
puters for financial analysis is inescap¬ 
able. And there are more than 100 secu¬ 
rities companies throughout the world. 
It is a substantial market. 

In addition to the established appli¬ 
cations of supercomputers in defense, 
aerospace, automotive, and science, 
ever-expanding complexity is increas¬ 
ing the need for high-performance com¬ 
puting in many additional fields, ac¬ 
cording to Jeff Kalb, president of Mas- 
Par Computer. These fields include 

• health care analysis; 

• environmental modeling; 

• continuous speech recognition; 

• model-based vision; 

• image processing and recognition; 

• similarity searching; 

•interactive content-sensitive text 

retrieval; 

• new classes of design and analysis 
tools; and 

• the modeling of economic, business, 
or physical systems too large, too 
distant, too complex, or too transient 
for current computers to deal with. 


Moreover, higher capacity computers 
can “predict” the behavior of complex 
systems, rather than merely report after 
the fact. 

Transaction processing on large da¬ 
tabases is a bread-and-butter task for 
most large businesses. It has usually 
been accomplished on mainframes. Now, 
Ncube and Oracle say they have dem¬ 
onstrated the viability of massively par¬ 
allel supercomputers for this mainstream 
business application. A 64-processor 
Ncube 2 running the Oracle Parallel 
Server database management system, 
version 6.2, has achieved a performance 
of 1,073 transactions per second on the 
Transaction Processing Performance 
Council Benchmark B. 

This performance was approximately 
twice that of any mainframe solution, 
said Michael Meirer, Ncube president. 
Cost per transaction was about one- 
twentieth of the cost of a high-end main¬ 
frame system. The achievement sounds 
like a foot in the door to another large 
application area. 

Reliable operation is important to 
many potential new applications, as well 
as to existing ones. Tim Browne of Think¬ 
ing Machines points out that massively 
parallel systems are inherently redun¬ 
dant. The new CM-5 Connection Ma¬ 
chine was designed to take advantage of 
this fact. It continuously monitors its 
own operations, looking for inconsis¬ 
tencies that might signal a problem. 
When it finds one, it transfers control to 
a dedicated diagnostic network. The 
diagnostic tests probable culprits, iso¬ 
lates malfunctioning subsystems, and 
switches in spare units. Faultless opera¬ 
tion continues. 

There is a big emphasis on transfer¬ 
ring this technology to private industry, 
Hayes of Los Alamos summed up. 
More and more people who never 
thought they could use a supercom¬ 
puter will undoubtedly have one in their 
future. ■ 


The Supercomputing 91 proceed¬ 
ings, Order No. 2158, is available 
from the Computer Society Press, 
Los Alamitos, California, by calling 
(800) CS-BOOKS or (714) 821- 
8380 in California. 

See p. 105 for more information 
about new supercomputing prod¬ 
ucts. 
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Conference on Object-Oriented Programming 
Systems, Languages, and Applications 

CALL FOR PARTICIPATION 

18-22 October 1992 , Vancouver, British Columbia, Canada 

The annual OOPSLA conference is the premier forum bringing together researchers, developers, and practitioners to 
share ideas and experiences related to object technology. Areas of interest include but are not limited to: language 
design and implementation, tools and environments, components and frameworks, user interfaces, principles and 
theory, concurrent and distributed systems, databases and persistence, design methods and software engineering 
practices. OOPSLA provides a unique opportunity to share your research and experience with other leaders in these 
areas of software development. 

We invite you to participate in OOPSLA ’92. Original submissions are invited in a variety of participation styles: 
Research and Experience Papers, Experience Reports, Panels, Demonstrations, Tutorials, and Workshops. New addi¬ 
tions to the program in ’92 are Poster Sessions and a special one-day Educators’ Symposium. 
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IMPORTANT DATES 

1 March 1992 

20 May 1992 

Papers due 

Contributors notified of 

1 April 1992 

acceptance 

Experience reports due 

20 June 1992 

Tutorial proposals due 

Camera-ready papers due 

Workshop proposals due 

Camera-ready panel position 

Panel proposals due 

papers due 

Poster proposals due 

Poster write-ups due 

Demonstration proposals due 
Educators’ symposium 
proposals due 

20 July 1992 

Camera-ready tutorial notes due 

Topics 

Papers 


Topics of interest include but are not limited 
to the following 

Language Design and 
Implementation 

Programming languages and specific 
.anguage constructs, visual programming 
languages, integraSonwith other program- 
JtflWSl&te, cmn&M an techniques, 
implementation techniques, storage manage¬ 
ment, ierfornint» i|||rsis, architectural 
support, embedded system's 

Tools and Environments 

Programming environments, software 
development tools, application specific 
development environments, debugging 
tggls, measurement tools 

Components and 
Frameworks 

Evaluations of reusable components, toolk¬ 
its, application development frameworks, 
user interface management systems, archi¬ 
tectural prlncipleslor reusable components, 
event-driven architectures,»eil«*aints 

Principles and Theory 

Conceptual ana sun-antic models, type sys¬ 
tems and type Inference, inheritance, delega¬ 
tion, reflection 

Concurrent and Distributed 

Systems «^Sm* 

Adels artff iSigsipItt^gport concurrent 
«Jd dls&ibuted processing, transaction mod¬ 
els, distributed object architectures, open 
systems, operating systems oevelopment 
and debugging tools, heterogeneous sys¬ 
tems, security 

ROCESSES 

Development methods, measurements of 
impact on productivity, reuse, or quality, 
specificat on jpimques, prototyping tech¬ 
niques, debugging and testing issues, man- 
agement issues, teaching, technology adop¬ 
tion, metrics, software evolution 

Databases and Persistence 

Bata models, database-programming lan¬ 
guage interfaces, persistent programming 
languages, implementation techniques, 
object servers, performance analysis 


The conference will include both invited and 
contributed papers. Authors are encouraged 
to submit high quality papers describing rel¬ 
evant research or experience. Research 
papers should describe work whose purpose 
is to advance the state of the art of object 
technology. Experience papers should 
describe the practical application of object- 
oriented methods. The program committee 
will evaluate each paper on its relevance, 
clarity, correctness, originality, and signifi¬ 
cance. Special consideration will be given to 
promising experience papers. Papers must 
not be under consideration elsewhere (or 
published) in the same or similar form. Do 
not submit multiple papers describing 
essentially the same work. 

Authors should send six copies of the full 
paper, in English, to the program chair to be 
received no later than 1 March 1992. 
Papers must be limited to 18 pages, typed 
double spaced. Each copy must contain 
sonant information (contact name, postal 
address, and phone number), a 100-word 
Abstract, and indicate the paper category 
(research or experience). Submissions fail¬ 
ing to meet these conditions will be rejected. 
Authors will be notified of acceptance or 
rejection by 20 May 1992. Camera-ready 
copies of accepted papers are due 20 June 
1992. Authors of accepted papers are 
expected to sign an ACM copyright release 
form and present the paper at the conference. 
Proceedings will be distributed at the confer¬ 
ence and via SIGPLAN Notices and will be 
available from ACM Press. Outstanding 
papers may be considered for a special issue 
of a journal. Guidelines for authors are pub¬ 
lished in the proceedings of the OOPSLA '91 
conference, or can be obtained from the pro¬ 
gram chair. 


Send submissions to: 

Rebecca Wirfs-Brock 
OOPSLA ’92 Program Chair 
16200 SW Pacific Hwy 
Suite 187 
Tigard, OR 97224 
Send correspondence to: 


Successful panels focus on raising issues 
and fostering stimulating discussion. OOP¬ 
SLA panels should present interesting and 
divergent views on interesting topics in 
object-oriented systems and languages. 
Panels typically involve four or five speakers 
making brief position statements, followed 
by extended discussion. Other innovative 
formats are encouraged. Panels will be pre¬ 
sented in parallel with the papers. They will 
be 90 minutes in length, with at least 45 
minutes allotted tor discussion and debate. 
Submission Requirements: 

• Panel title. 

• Brief summary of the key issues to be 
discussed. 

• Each panelist’s name, background and 
a short description of his/her position 
on the issues. 

• Contact information for the panel 
moderator (name, affiliation, address 
and phone number). 

Panel proposals must be received by 
1 April 1992. Proposers will be notified of 
acceptance by 20 May 1992 and the final 
camera-ready versions of position papers tor 
publication in the conference proceedings 
will be due on 20 June 1992. 

Address submissions and questions to: 


Experience Reports 

Space will be made available in a separate 
track for short presentations of unrefereed 
reports describing practical experience 
applying object technology to production 
quality software development. Prospective 
speakers should submit a 1-2 page descrip¬ 
tion of the project scope and status and the 
specific points to be covered in the presenta¬ 
tion to the program chair by 1 April 1992. 
Selection will be based on relevance and 
potential interest. Summaries will be col¬ 
lected after the conference for publication in 
the Proceedings Addendum. 

Send submissions to: 

Rebecca Wirfs-Brock 
OOPSLA '92 Program Chair 
16200 SW Pacific Hwy 
Suite 187 

Tigard, Oregon 97224 


Send correspondence to: 

Rebecca Wirfs-Brock 
OOPSLA '92 Program Chair 
Instantiations, Inc. 

921 SW Washington, Suite 312 
Portland, OR 97205 
Phone: +1-503-242-0725 
Fax: +1-503-242-0729 
Email: rebecca@instance.com 


Proposals are invited for tutorials covering 
subjects of interest to the object-oriented 
community. Tutorial proposals are solicited 
at all levels - introductory, intermediate and 
advanced. Proposals for tutorials covering 
advanced topics are especially welcomed. 
Tutorials offer a forum for educating profes¬ 
sionals and give attendees the opportunity to 
take an in-depth look at topics of their choice 
in intensive half, full, or two-day sessions. 

All tutorial proposals will be reviewed. 
Tutorials will be selected on the basis of 
importance of the topic, expertise of the pre¬ 
senters, and the educational value of the 
material to be presented. Product marketing 
or selling are inappropriate in this forum. 


Phone: +1-503-242-0725 
Fax: +1-503-242-0729 

Email: rebecca@instance.com 




tions of system designs are very appropriate. 
Anyone considering submitting a proposal 
for a tutorial should request guidelines on 
tutorial submissions from the tutorial chair. 
Copies of the proposal must be received by 
1 April 1992. Proposers will be notified of 
acceptance by 20 May 1992 and the final 
camera-ready versions of tutorial materials 
for publication in the tutorial notebooks will 
be due on 20 July 1992 
Send requests for tutorial submission 
guidelines to: 

Ralph Johnson 
OOPSLA ’92 Tutorials Chair 
Department of Computer Science 
1304 W. Springfield Ave. 

Urbana, IL 61801 
Phone: +1-217-244-0093 
Fax: +1-217-333-3501 

Email: johnson@cs.uiuc.edu 

Demonstrations_ 

Proposals are invited for live demonstrations 
of systems that use, apply, or teach object- 
oriented programming and technology. 
Demonstrations will be selected on the basis 
of technical merit, relevance to object-orient¬ 
ed programming, novel and interesting fea¬ 
tures, and feasibility. Presenters should be 
members of the development or implementa¬ 
tion team and should be prepared to give a 
technical presentation to a technical audi¬ 
ence. Product marketing or selling are inap¬ 
propriate in this forum. 

Demonstrations of both commercial and in- 
house applications, as weft as academic and 
corporate research efforts are sought. In 
addition to new efforts, we are also interested 
in “where are they now” demonstrations of 
projects shown in previous years. 
Demonstrations should not exceed 30 min¬ 
utes. Proposals for demonstrations must 
include a one-page abstract providing the 
title and description of the demonstration, 
and the names, affiliations, addresses (postal 
and electronic), and phone number of the 
demonstrators. In addition, a description of 
the technical and hardware requirements for 
the demonstration is needed. While every 
effort will be made to provide equipment, 
demenstrators may be asked to provide their 
own equipment or to make arrangements tor 
sharing equipment. For details contact the 
Demonstrations Chair. Three copies of the 
proposal, including the abstract and techni¬ 
cal requirements, must be received by 
1 April 1992. Proposers will be notified of 
acceptance by 20 May 1992. 



















Send submissions to: 

Rebecca Joos 

OOPSLA '92 Demonstrations Chair 
Motorola, Inc. 

6501 William Cannon Drive 

Austin, Texas 78735 

Mail Drop: OE112 

Phone: +1-512-891-3617 

FAX: +1-512-891-3798 

Email: beckyj@oakhill.sps.mot.com 


Workshops 


Workshops are a means for experts to meet 
and discuss issues with a selected focus - an 
opportunity for researchers and practitioners 
to compare notes. They provide a forum for 
the thrust-and-parry of real scientific dis¬ 
course. The workshops also provide an 
opportunity for representatives of a research 
community to coordinate efforts and estab¬ 
lish plans of action. 

To ensure a sufficiently small group for open 
interchange, each workshop is limited in the 
number of participants. Participants are 
chosen on the basis of a position paper out¬ 
lining their opinions on an aspect of the 
workshop topic. Presentations are at the 
discretion of the workshop organizers but all 
attendees are expected to join in the debate. 
After the workshop, the organizer(s) will be 
responsible for reporting to the OOP com¬ 
munity via an article in the Proceedings 
Addendum. 

If you wish to organize a workshop, send a 
description of the topic and intended audi¬ 
ence to be received by 1 April 1992 
Proposals should include the workshop 
organizer's name, affiliation, address (postal 
and electronic), and phone number. 
Proposers will be notified of acceptance by 
20 May 1992 Electronic submissions will 
be greatly appreciated. 

Send submissions to: 

John D. McGregor 
OOPSLA '92 Workshops Chair 
Dept, of Computer Science 


include an extended abstract limited to 8 
pages (typed double spaced). A separate 
cover sheet must contain the name, affilia¬ 
tion, address, phone number, and email 
address of all authors. Indicate a primary 
contact person. Include a list of indexing 
keywords using the Computing Reviews 
Classification System terms and also a pre¬ 
liminary graphic layout of the poster. 

Send submissions to: 

Mark A. Whiting 
OOPSLA '92 Posters Chair 
Battelle Pacific Northwest Laboratory 
PO Box 999 MS K7-22 
Richland, WA 99352 


Clemson, SC 29634-1906 
Phone: +1-803-656-5859 
Fax: +1-803-656-0145 

Email: johnmc@cs.clemson.edu 

Posters 

The Poster Session will provide a forum for 
one-to-one and small group interaction 
about specific object-oriented work— either 
theoretical or applied in nature. Acceptable I 
posters should provide both visual impact 
and the ability to stimulate interaction among 
attendees. We especially invite work in 
progress, work by students, work concerning 
new methods and processes, and work con¬ 
cerning controversial topics. 


are required to be available during designat¬ 
ed times (estimated 4 hours total). Write ups 
of accepted posters will be available at the 
conference. 

Authors should send 4 copies of a proposal 
to the Poster Session Chair to be received no 
later than 1 April 1992. Authors will be 
notified of acceptance by 20 May 1992. 
Final copies of the poster write-up will be 
due on 20 June 1992. Proposals must 


USA 

Phone: +1-509-375-2237 
Fax: +1-509-375-3641 

Email: whiting@snuffy.pnl.gov 
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OOPSLA has always been an important 
resource for educators. For the first time, 
OOPSLA '92 will offer a special one-day pro¬ 
gram specifically designed for computer sci¬ 
ence educators. The Educators' Symposium 
will provide a forum for members of academ¬ 
ic institutions interested in getting started, or 
sharing experiences, in teaching object-ori¬ 
ented concepts as part of a normal computer 
science curriculum. The Symposium will 
presentations, panels, invited talks 
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Conference on Object-Oriented Programming 
Systems, Languages, and Applications 

CALL FOR PARTICIPATION 

18-22 October 1992 , Vancouver, British Columbia, Canada 


Proposals for "experience, lessons learned” 
presentations are solicited from educators. 
Topic areas include the introduction of OOP 
as a student’s first programming experience 
as well as teaching OOP concepts in general, 
to more experienced students. Proposals for 
live demonstrations of software systems that , 
aid in the teaching of OOP in a university 
environment are also invited. 

Mail or tax three copies pl an extended 
abstract for presentations (3-6 pages) or a 
brief project/product description for demon¬ 
strations.^ pages), to be received no later §| 
than 1 April 1992 Proposers witl be noti¬ 
fied of acceptance by 20 May 1992 A sep¬ 
arate cover pheet must contain the name, 
affiliation, address, phone number, and 
^Emait address of author or contact perppn. 

For more details on the Educators' 

Symposium program contact the co-chairs. J 
Please send submissions to James Heliotis. ij 
James E. Heliotis 
OOPSLA ’92 Educators’ 

Program Co-Chair 
Rochester Institute of Technology 
1 Lomb Memorial Drive 
Rochester, NY 14623-0887 
Phone: +1-716-475-6133 
Fax: +1-716-475-7100 

Email: jeh@cs.rit.edu 
Mary Beth Rosson 
OOPSLA ’92 Educators’ 

Program Co-Chair 
IBM T J Watson Research Center 
PO Box 704 

Yorktown Heights, NY 10598 
Phone: +1-914-784-7738 
Fax: +1-914-784-7279 

Email: rosson@watson.ibm.com 


Student Volunteers_ 

The top people in object-oriented technolo¬ 
gies and software development will meet at, 
speak at, and run the OOPSLA '92 confer¬ 
ence. The student volunteers program is an.,, 
opportunity for students to associate with 
these world experts. In trade tor about ten 
hours of their time, students wilt receive a 
complimentary registration and other bonus 
benefits. In the past, job assignments have 
included checking badges at doors, assisting 
with tutorials and panels, and general go-lor 
p the conference running 
d graduate and under- 
ts should contact the student 
volunteers chairperson (a former student 
volunteer himself) no later than 15 August, 
1992. Email is greatly preferred tor all cor¬ 
respondence. 

Bjorn Freeman-Benson 

OOPSLA 92 Student Volunteers Chair 

University of Victoria 

P.O. Box 3055 

Victoria, British Columbia 

Canada V8W 3P6 

Phone: +1-604-721-6019 

Fax: +1-604-721-7292 

Email: bnfb@csr.uvic.ca 

Exhibits_ 

Running concurrently with the technical pro¬ 
gram wilt be an exposition of object-oriented 
programming product and service vendors. 

In addition to continuous exposure in their 
booths in the Exhibition Hall, exhibitors have 
the opportunity to make scheduled presenta¬ 
tions as part of the Vendor Forum, an inte¬ 
gral part of the OOPSLA '92 program. 

Vendors also have special access to the 
Increasing numbers of press representatives 
attending OOPSLA. Press conferences can 
be scheduled in advance for new product 
and service announcements. Press room 
facilities are available tor press kit distribu¬ 
tion. A press attendee list is available to 
exhibitors in advance of the Conference 
opening 

Potential exhibitors should contact the /f1 
Exhibits Co-Chairs at the earliest conve¬ 
nience to ensure their inclusion in the OOP¬ 
SLA 92 Exhibits. 

Timlynn Babitsky and Jim Salmons 
OOPSLA '92 Exhibits Co-Chairs 
JFS Consulting 
7 Wise Ferry Court 
Lexington, SC 29072 


OOPSLA '92 


Seventh Annual ACM Conference on Object- 
Oriented Programming Systems, Languages, 
and Applications 


Direct all specific correspondence to the 
appropriate committee members. General 
correspondence on OOPSLA 92 may be 
sent to: 

John Pugh 

OOPSLA ’92 Conference Chair 
PO Box #4879 
Postal Station ‘E’ 

Ottawa, Ont. 

Canada K1S5J1 
Phone: +1-613-225-1871 
Fax: +1-613-225-5943 

Email: oopsla92@carleton.ca 
Operations questions should be directed to: 
Jeff McKenna 

OOPSLA ’92 Operations Chair 
The McKenna Consulting Group 
32514 SW Juliette Drive 
Wilsonville, OR 97070-7444 


Registration/ 

Conference Information 

An advance program containing tutorial 
information, registration forms, housing 
forms, and preliminary technical information 
will be mailed in June 1992 it you attend¬ 
ed the 1990 or 91 OOPSLA conferences or if 
you are a member of ACM/SIGPLAN. you 
will automatically receive a copy of the 
advance program brochure. Otherwise. 

5 contact: 


+1-407-628-3602 

+1-407-628-3186 

mann@eola.cs.ucf. 



Reader Service Number 2 


Computing Machinery's Special 
Interest Group on Programming 
Languages (ACM/SIGPLAN) 
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Editor: Guylaine M. Pollock, Sandia National Laboratories, Division 1424, PO Box 5800, Albuquerque, NM 87185; phone (505) 845-7463; Internet gmpollo@cs.sandia.gov 


Computer Science Accreditation Commission list tops 100 


The Computer Science Accredita¬ 
tion Commission (CSAC) of the Com¬ 
puting Sciences Accreditation Board 
(CSAB) has added 12 new programs 
to its accreditation list, bringing the 
total to 107. 

CSAC is the accrediting body for 
baccalaureate computer science pro¬ 
grams in the US and is recognized by 
the Council on Postsecondary Accred¬ 
itation and the US Secretary of Edu¬ 
cation. It accredits programs designed 
to prepare graduates for entry into the 
computer science profession. 

Programs accredited by CSAC meet 
or exceed CSAC/CSAB criteria re¬ 
quirements for faculty, curriculum, 
laboratory and computing facilities, 
students, and institutional support. 

The accreditation process requires 
that the institution submit a compre¬ 
hensive self-study of the program, and 
includes a campus visit by a CSAC 
evaluation team. 

CSAB was founded in 1984 by the 
ACM and the IEEE Computer Soci¬ 
ety in response to concerns about 
quality, consistency, and professional 
outcomes for graduates of computer 
science programs. 

The 12 programs listed below (al¬ 
phabetically by state) were accredited 
by CSAC in 1991. The names of the 
95 previously accredited programs 
were published in the October 1990 is¬ 
sue of Computer , pp. 76-77. 

For more information about the ac¬ 
creditation process, including a copy 
of the “CSAC/CSAB Criteria for Ac¬ 
crediting Programs in Computer Sci¬ 
ence in the United States,” call or 
write to Patrick M. LaMalva, Execu¬ 
tive Director, Computing Sciences 
Accreditation Board, 345 East 47th 
St., New York, NY 10017; phone 
(212) 705-7314; e-mail 
lam@timessqr.gc.cuny.edu. 

The newly accredited programs are 
as follows: 

Alaska 

University of Alaska Fairbanks, 

Fairbanks 

BS computer science 


Florida 

Florida Atlantic University, Boca 
Raton 

BS computer science 
Georgia 

Armstrong State College, Savannah 
BS computer science 

Kentucky 

Eastern Kentucky University, Rich¬ 
mond 

BS computer science 
Louisiana 

Louisiana State University in 
Shreveport, Shreveport 
BS computer science 

Mississippi 

Jackson State University, Jackson 
BS computer science (mathemat¬ 
ics-oriented concentration) 

New York 


The IEEE Computer Society’s 
Nominations Committee is selecting 
nominees for 1993-94 IEEE Division 
VIII delegate-director and 1993 Divi¬ 
sion V delegate-director-elect. The 
new Division VIII director will re¬ 
place Helen M. Wood, who will com¬ 
plete her term at the end of this year. 
The selection of a Division V director- 
elect anticipates final approval of a 
bylaws amendment currently open for 
member comment and pending sec¬ 
ond approval by the Computer Soci¬ 
ety Board of Governors ( Computer , 
Nov. 1991, pp. 82-84). 

Because of the complexity of the 
IEEE division delegate-director posi¬ 
tion, the Computer Society’s 1991 
Planning Committee recommended 
that the society elect division directors 
one year earlier, as division delegate- 
directors-elect, to provide volunteers 


State University of New York at 
New Paltz, New Paltz 
BS computer science 

Ohio 

University of Dayton, Dayton 
BS computer science 
University of Toledo, Toledo 
BS computer science and engi¬ 
neering (dually accredited by the 
Engineering Accreditation Com¬ 
mission of the Accreditation 
Board for Engineering and Tech¬ 
nology) 

Pennsylvania 

Bucknell University, Lewisburg 
BS computer science 
Villanova University, Villanova 
BS computer science (College of 
Arts and Sciences) 

Virginia 

Norfolk State University, Norfolk 
BS computer science 


with a year to observe and learn about 
the responsibilities of the position. 

The person chosen as Division V dele- 
gate-director-elect would serve in that 
position in 1993 and then as the divi¬ 
sion’s delegate-director for 1994-95. 

In addition to candidates selected 
by the Nominations Committee, can¬ 
didates may be nominated by member 
petition until May 31. Nominations 
should be submitted to Duncan H. 
Lawrie, Nominations Committee 
Chair, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903. Com¬ 
plete information on petition candi¬ 
date procedures is available from 
Mercy Kowalczyk, IEEE Headquar¬ 
ters, 345 E. 47th St., New York, NY 
10017. 

Candidates will appear on the IEEE 
ballot for the fall 1992 election. 


Society seeks nominations for IEEE division 
delegate-directors 
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Send news about research, public policy, or professional issues to Bob Carlson, Computer, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264 


Entries invited for 1992 Gordon Bell Prizes 


Entries are now being sought in the 
1992 Gordon Bell Prize competition. 
The prizes recognize outstanding 
achievements in the application of 
parallel processing to practical scien¬ 
tific and engineering problems. The 
due date for entries is May 1. Finalists 
will be announced by June 30, and 
winners will be announced at Super¬ 
computing 92 in November. 

Oil exploration and extraction, inte¬ 
grated-circuit design, evolution re¬ 
search, space-shuttle modeling, turbu¬ 
lence simulation, and mortgage-rate 
determination are some of the appli¬ 
cations addressed by previous recipi¬ 
ents. 

Two prizes of $1,000 will be given. 
Entries in the following three catego¬ 
ries will be considered: 

• Performance: The entrant will be 
expected to convince the judges that 
the submitted program is running fast¬ 
er than any other comparable engi¬ 
neering or scientific application. Suit¬ 
able evidence will be the megaflop 
rate based on actual operation counts 
or the solution of the same problem 
with properly tuned code on a ma¬ 
chine of known performance, such as 
a Cray Y-MP. If neither of these mea¬ 
surements can be made, the submitter 
should document the performance 
claims as well as possible. 

• Price/performance: The entrant 
must show that the performance of 
the application divided by the list 
price of the smallest system needed to 
achieve the reported performance is 
better than that of any other entry. 
Performance measurements will be 
evaluated as for the performance 
prize. Only the cost of the CPUs, 
memory, and any peripherals critical 
to the application need be included in 
the price. For example, if the job can 
be run on diskless compute servers, 
the cost of disks, keyboards, and dis¬ 
plays need not be included. Entrants 
must demonstrate that the machine 
they used has real utility. (Picking up 
a few used Z-80s for $1 each is not ac¬ 
ceptable.) Only list prices of compo¬ 
nents should be used. If the machine 
is not on the market, the entry is 


probably not eligible, although the 
judges will consider any reasonable 
estimate of the price. 

• Compiler parallelization: Judges 
are looking for the combination of 
compiler and application that gener¬ 
ates the greatest speedup. Speedup 
will be measured by dividing the wall- 
clock time of the parallel run by that 
of a good serial implementation of the 
same job. These may be the same pro¬ 
gram if the entrant can convince the 
judges that the serial code is a good 
choice for a uniprocessor. Compiler 
directives and new languages are per¬ 
mitted. However, anyone submitting 
an entry in other than a standard, se¬ 
quential language will have to con¬ 
vince the judges that the parallelism 
was detected by the compiler, not by 
the programmer. 

Some general conditions apply: 

(1) The submitted program must 
have utility; it must solve a problem 
that is considered a routine produc¬ 
tion run. It should not be a contrived 


The National Science Foundation 
Scientific and Engineering Database 
Access Project, known as NACSIS, is 
offering an update service that focuses 
on areas of significant Japanese re¬ 
search that are of special interest to 
the American research community. 
Each “Hot Topics” package contains 
the most recent 100 abstract records 
retrieved from the NACSIS confer¬ 
ence proceedings databases. Updates 
are provided periodically as new 
records are added to the databases. 

The subject areas are 

• Al/expert systems 

• applied biotechnology 

• biomedical electronics 

• CAD/CAM-CIM 

• ceramics 

• database technology 

• electronic displays 

• integrated circuits 

• neural networks 


or experimental problem intended 
just to show high speedup. 

(2) In all categories judges will con¬ 
sider how much the entry advances 
the state of the art in some field. For 
example, an entry that runs at 15 
Gflops but solves a problem in a day 
that previously took a year might win 
over an entry that runs at 20 Gflops 
solving a more mundane problem. 

(3) The burden of proof is on the 
contestants. The judges will make an 
honest effort to compare the results of 
different programs solving different 
problems running on different ma¬ 
chines, but they will depend primarily 
on the submitted material. 

The prizes are sponsored by Gor¬ 
don Bell, a former National Science 
Foundation division director who is 
now an independent consultant. 

Contestants should send a three- or 
four-page executive summary to 1992 
Gordon Bell Prize, do Marilyn Potes, 
IEEE Computer Society, 10662 Los 
Vaqueros Cir., PO Box 3014, Los Ala¬ 
mitos, CA 90720-1264, before Mayl. 


• NLP/machine translation 

• optoelectronics 

• parallel computing 

• polymers 

• robotics 

• sensors and sensing 

• telecommunications 

Those interested in having searches 
done on the NACSIS databases or in 
obtaining Hot Topics packages — 
both free of charge — may contact the 
NACSIS operator at (202) 357-7278 
between 1 and 4 p.m. EST on week¬ 
days. E-mail messages may be sent to 
nacsis@nsf.gov (Internet) or 
nacsis@nsf (Bitnet). 

Full details on the NACSIS data¬ 
bases may be found in the NSF’s Ja¬ 
pan Program Announcement, NSF 90- 
144. Order from the NSF’s 
Publication Unit, Room 232, NSF, 
Washington, DC 20550; phone (202) 
357-3619. 


Updates on Japanese research available 
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The Eighth IEEE Conference on 

ARTIFICIAL 
INTELLIGENCE for 
APPLICATIONS 



March 2-6, 1992 
Doubletree Hotel 
Monterey, California 

Timothy Finin, General Chair Donald McKay, Workshop Chair 
Jan Aikins, Program Chair Curt Hall & Paul Harmon, Publicity Chairs 
Dan O’Leary, Tutorial Chair Bob Engelmore, Local Arrangements Chair 

The Eighth IEEE Conference on Artificial Intelligence for Applications (CAIA-92) is devoted to the application of artificial intelli¬ 
gence techniques to real-world problems. This year’s conference will focus on both case studies and advances in AI techniques and the 
principles that underlie knowledge-based systems and which enable ever more ambitious real-world applications. This conference 
provides a forum for such synergy between applications and AI techniques. 

Tutorial sessions will be held on Monday, March 2 and Tuesday, March 3. The technical program sessions will be Wednesday, March 4 
through noon, Friday, March 6. 

KEYNOTE AND PLENARY TALKS: 

• AI Applications at NASA: Hindsight and Foresight, Dr. Melvin Montemerlo, NASA 

• Software Patents and Copyrights: How Did We Get Into This Mess? And How Do we Get Out? Dr. Randall Davis, MIT 

• The Calculus of Fuzzy If-Then Rules and Its Application, Dr. Lotfi Zadeh, University of California 

INVITED SPEAKERS: 

• Standards and Standardization: Assured Incompatibility? Carl Cargill, DEC 

• Overview of Standards Activities, Earl Sacerdoti, The Copemican Group 

• Task Specific Architectures in Knowledge-Based Systems: Progress and Issues, B. Chandrasekaran, Ohio State University 

PANELS: 

• The Proper Role of Standards in AI 

• As CASE Approaches AI . . . 

• Extracting Information from Text 

• Case-Based Reasoning: Ready for Prime Time? 

TUTORIALS: 

• Knowledge Acquisition 

• Knowledge-Based Production Management 

• Case-Based Reasoning 

• Real-Time Knowledge-Based Systems 

• CASE, Knowledge-Based Systems & OOP 

• Verification and Validation 


• Data Mining and Information Creation 

• Scheduling Technologies 

• Integrating Information Technologies in AI 


• Planning Systems 

• Rules from Examples 

• Project Management 

• Software Design 

• User Interface Design 

• Behavior-Based Reactive Robotics 


WORKSHOPS (By Invitation): 

• Applying AI to Software Problems: Assessing Promises and Pitfalls 

• Artificial Intelligence for Customer Service and Support 

For information about attending the workshops, contact: Don McKay, Unisys Defense Systems, Inc., P.O. Box 517, 

Paoli, PA 19301 

PROGRAM TOPICS: Integrating Rule-Based Systems • Enabling Technologies • Diagnosis • Planning, Scheduling & Constraint 
Satisfaction • Knowledge Acquisition & Learning I, II • Intelligent Interfaces & Natural Language Processing • Case-Based Reasoning, 
Genetic Algorithms & Fuzzy Logic • Design • Distributed Problem Solving & Real-Time Systems 

A special feature of the conference will be a series of talks and panels on the various AI standardization efforts being considered by 
various bodies. 

FOR ADDITIONAL INFORMATION: A complete Advance Program, including a conference registration form, can be obtained 
from the IEEE Computer Society, 1730 Massachusetts Ave., N.W., Washington, DC 20036-1903; (202)371-1013. 
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Editor: Richard Eckhouse, University of Massachusetts-Boston. 
Send review submissions to MOCO Inc., 776A Country Way, N. Scituate, MA 02066; Compmail r. eckhouse; Internet, eckhouse@cs.umb.edu. 


Windows programming environments 

Noah Davids, Stratus Computer 


The past year has seen an explosion 
of Microsoft Windows 3.0 program¬ 
ming environments. In fact, we have 
six of them for review. The six fall 
into four distinct groups. 

The programming languages for 
ObjectScript and Realizer are similar 
to Basic. Actor and Smalltalk/V are 
object-oriented environments. Bor¬ 
land C++ is also object-oriented but 
looks and feels like C. KnowledgePro 
comes from an artificial intelligence 
environment and reminds me a little 
of Lisp. While all these environments 
let me write Windows applications, 
you will see that some made it easier 
than others. 


ObjectScript 1.21 

ObjectScript lets you access files and 
directories — and launch applications 
— without any programming. This 
$150 program lets you, in essence, 
create customized front ends. You 
can also associate a script with each 
object. The scripts range from simply 
launching an application or displaying 
another object window to complex 
data manipulation and interactions. 
The objects are buttons, text-input 
boxes, and menu bar items — anything 
that can appear in the window. 

A complete Basic-like programming 
language called Script provides func¬ 
tions that access a range of Window 
features as well as standard file I/O. 
Script functions also let users create, 
read, and write dBase III data files and 
Ndx index files. 

The ObjectScript manual, however, 
sets new lows for computer documen¬ 
tation. While it adequately covers the 
user interface to the editor, compiler, 
and runtime applications and explains 
the Script language structure well 
enough, the manual discusses the 
functions and procedures (which give 
the language its power) in a small, in¬ 
adequate paragraph. The authors 
probably felt that the on-line exam¬ 
ples were sufficient. They might be 
right, but it’s not easy to find specific 
functions in all the examples. The 
manual’s incomplete index makes it 


difficult to locate subject matter. For 
example, if you are looking for a de¬ 
scription of the string data type, you 
will look in vain under data type, 
string, or variable. There are also 
many references to the Windows Dy¬ 
namic Data Exchange interface 
throughout the manual, but the index 
lists only one page under DDE — and 
that page doesn’t mention it. To be 
fair, let me point out that some exam¬ 
ples, like the help system, are useful 
and can be incorporated into other 
applications. 

ObjectScript is really three integrat¬ 
ed applications. Obedit lets you build 
a window and place objects in it. Ob- 
comp lets you edit and compile a 
script, while Obscript runs an applica¬ 
tion composed of a window definition 
and the compiled script. You can 
bring up the compiler (and run the 
application) from the editor. I found 
it easy to switch from one function to 
the other while I was testing and de¬ 
bugging my applications. 

You start building the application 
by adding objects to the default win¬ 
dow. Objects are added by choosing 
from the list presented when you se¬ 
lect the object menu item. An object 
appears in the window, and then you 
drag and size it. (You can change size 
and position later.) Double-clicking 
on an object selects it and allows you 
to set or change its properties. These 
properties include the events to be 
processed by the object (like a mouse 
click), the keyboard focus, and the 
command to be run when the event is 
processed. 

This program has many powerful 
commands. You can build a window 
containing a list box and an edit box. 
When the application starts, the list 
box is filled with all files in the cur¬ 
rent directory. When one is selected, 
it’s loaded into the edit box. Selecting 
a button in the window by its graphic 
runs a specific application or displays 
another ObjectScript window. These 
commands let a nonprogrammer con¬ 
struct some useful applications with¬ 
out doing any “programming.” 

The Script language, while greatly 
expanding the functionality and pow¬ 


er of applications, is very hard to use. 
There is no debugging support other 
than the capability for displaying a 
simple message box to confirm that a 
code path has been executed and to 
show variable values. Syntax errors in 
the script can generate misleading 
(but clearly stated) error messages 
from the compiler. Finally, the meth¬ 
od for loading graphics into a picture/ 
text object is not obvious. You must 
first load the Bmp (Windows bit¬ 
mapped file) picture into the mini¬ 
album database (which comes with 
ObjectScript) and then refer to the 
file that the mini-album creates. For 
bitmapped files, this will be a Bmp file 
— but not a standard one. If you try 
to load a standard Bmp file, it will not 
work. However, no error messages 
will accompany the process. 

I also discovered a few things that 
the language cannot do at all. First, 
there is nothing in the language that 
allows you to send text to a printer. 
For example, for your application to 
generate a report, you must write it to 
a file and then print the file by some 
other means. You also cannot set the 
background color of input, edit, and 
list objects. That color must match the 
background color set for MS Win¬ 
dows. Text must also remain black. 
There is no control over the font and 
size of the text in input, edit, list box, 
and button objects, but for some rea¬ 
son you can control font and size in 
picture and text objects. 

Several other things about running 
an ObjectScript application make it 
less than ideal. The biggest problem is 
that “error recovery and diagnose” 
appears to be nonexistent. For exam¬ 
ple, calling for the execution of a pop¬ 
up modal window and a new script 
does not result in an error if the path 
to the new object window is incorrect. 
It just doesn’t get executed. Another 
problem is that you need either the 
ObjectScript development or runtime 
environment to run an application. 
The runtime environment is only $50, 
but it’s something that users of your 
application must already have. A mi¬ 
nor fallout of this is that you cannot 
create a custom icon for your Object- 
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Electronics Workbench update 

After our review on Electronics Workbench came out in Computer's September 
1991 issue (p. 133), the company informed us that it had repriced the current 
top-of-the-line Professional color version from $650 to $299 for the PC package. 
(A Personal Plus version, with many similar features, is $199, and a Personal 
version sells for $99.) Reviewer Dan Somerville had commented that the original 
price seemed a bit steep, and we thought our readers would appreciate knowing 
that Interactive Technologies did something about that. 

Readers may contact Interactive Technologies Ltd., 49 Bathurst St., Ste. 401, 
Toronto, Ont., Canada M5V 2P2 (or Interactive Image Technologies Ltd., 908 
Niagara Falls Blvd., North Tonawanda, NY 14120); or circle Reader Service 
Number 22. 


Script application; it will use the Ob- 
jectScript icon. 

The company’s technical support 
started out okay, but the more calls I 
made, the harder it was to get through. 
My last four calls were unanswered. 

ObjectScript teeters on the brink of 
being a useful application. The inte¬ 
gration of the editor, compiler, and 
runtime is very good. The Script lan¬ 
guage, while not a super language, is 
adequate for most tasks. All it needs 
is a better runtime error handler, im¬ 
proved debugging support, and docu¬ 
mentation that tells you how to use it 
all. 

To obtain this $150 package, read¬ 
ers can contact Matesys Corp. at 900 
Larkspur Landing Cir., Ste. 175, Lark¬ 
spur, CA 94939; (415) 925-2900; or 
circle Reader Service Number 21. 


Realizer 1.0 


This program lets you create Win¬ 
dows applications by using a superset 
of Basic. It gives you complete control 
of all objects in the window and their 
attributes. The complex calling se¬ 
quences for these control routines 
contain a great number of required 
and optional arguments. However, the 
documentation is very good. 

The program also has a number of 
useful and unique features. Arrays are 
not statically declared; they can grow 
simply by incrementing the array in¬ 
dex beyond the previous maximum 
value. Entire arrays and families — 
Pascal-like records — can be written 
to a disk file or read from a file with 
one I/O call. 

Besides Windows’ standard set of 
objects, Realizer provides five power¬ 
ful tools: Charts, Spreadsheets, 

Boards, Logs, and Scheduler. Charts 
provides a very high level interface 
for constructing line, x-y, and bar 
charts. The charts can have keys, la¬ 
bels, and titles; you can plot multiple 
arrays on one chart and control the 
color of each line or bar and the 
marker style for each point. 

The spreadsheets are just that — 
spreadsheets. However, interactively 
modifying a spreadsheet cell also 
modifies the underlining array ele¬ 
ment on which that cell is based. 
Spreadsheets can also be split hori¬ 
zontally or vertically to simultaneous¬ 
ly display different regions. Boards 
consists of specialized spreadsheets 
that let users view data without being 
interactive. Logs consists of text win¬ 
dows for both input and output. As in¬ 


put, they act like simple text editors. 
Clicking in these windows lets you 
associate each tool with an activated 
procedure. The x-y coordinate, cell 
coordinate, or character position is 
passed to the procedure so that the 
action taken depends on where the 
mouse is pointing when it is clicked. 
The final tool is the Scheduler. Only 
one Scheduler may be in an applica¬ 
tion (you can have any number of the 
other tools in a window). 

The Scheduler window looks like an 
appointment book, with a column for 
times, another for the command to be 
run at that time, and a third for the 
frequency. Because scheduled events 
are run when no other Realizer pro¬ 
gram is running, they will not inter¬ 
rupt the current application. Events 
can be added to the Scheduler only 
through program control, but they can 
be deleted either by the program or 
interactive means. You cannot associ¬ 
ate a procedure with the Scheduler. 

To build an application, you start by 
invoking the Realizer application. The 
window that comes up contains all 
other Realizer windows, including de¬ 
bugging, editing, and applications. A 
mouse click switches from one to an¬ 
other. However, unless the Realizer 
window is maximized, this scheme 
makes for a very cluttered window. 

It’s also hard to construct an applica¬ 
tion window because the objects and 
spacing are all scaled to the size of the 
Realizer window. This is my biggest 
(and just about the only) complaint 
about the package. 

A program consists of statements to 
display objects on the screen and pro¬ 
cedures that are activated when those 
objects are clicked. The FormDev 
utility is a Realizer application that 
helps to create this program. You se¬ 
lect an object from a palette, size it, 
and place it in a window. The palette 
contains both the standard Windows 
objects and the five Realizer tools. It 
also allows you to control all at¬ 


tributes of an object. You can then de¬ 
fine the procedure to be executed 
when the object is clicked upon. After 
creating the program, you must exit 
the FormDev utility to execute it. I 
found this procedure very cumber¬ 
some, as the FormDev utility is slow 
and hard to use. In addition, changes 
made directly to the generated source 
file are lost when FormDev generates 
a new version of the source file. For 
this reason, the utility is a good start¬ 
ing point for screen layouts, but after 
that, you should just edit the generat¬ 
ed application. 

Debugging support is excellent. 

You can open a debugging window 
to access variable values and step 
through the program one statement at 
a time, skip statements, or trace pro¬ 
cedure calls. You can also stop the 
program by pressing the stop button - 
or programmatically causing the pro¬ 
gram to stop - to enter the debugger. 
Since the code is interpreted, you can 
stop the program and edit the source 
to place a stop statement anywhere 
below the current point of execution. 
You can also change the value of any 
variable by typing in an assignment 
statement, executing just that state¬ 
ment, and continuing with the applica¬ 
tion program. You can correct errors 
that stop the program and restart it. 

You can distribute applications cre¬ 
ated by Realizer as either Realizer 
source code or an .EXE file. The 
source code can be unencrypted so 
that anyone with Realize can change 
it or encrypted so that it cannot be 
changed. Running the source code re¬ 
quires the Realizer runtime module; 
running the .EXE file requires a Real¬ 
izer Dynamic Link Library. Neither 
comes with the $395 Realizer pack¬ 
age. You do get a form for ordering 
the runtime module, which is free and 
may be distributed with applications 
free of charge. 

The technical support people I 
spoke with were helpful and knowl- 


COMPUTER 








edgeable, calling back with answers 
they could not provide on the spot. 

I liked Realizer because it hid most 
of the complexity of Windows pro¬ 
gramming while adding a minimum of 
its own. It could do everything that I 
asked and had a moderate learning 
curve. The five powerful tools should 
make building applications a snap. My 
only major complaint is the clumsy 
FormDev cycle. 

Readers can contact Within Tech¬ 
nologies Inc. at Laurel Corporate 
Center, Ste. 201, S. 8000 Midlantic 
Dr., Mount Laurel, NJ 08054; (609) 
273-9880; or circle Reader Service 
Number 23. 


Actor Professional 3.1 

Actor is an object-oriented lan¬ 
guage and environment that success¬ 
fully hides most of the complexity of 
programming a Windows application. 
However, it replaces one form of com¬ 
plexity with another. The object-ori¬ 
ented paradigm can shock anyone 
who is familiar with only procedural 
languages like C or Basic. I found the 
concepts of methods, messages, ob¬ 
jects, and inheritance confusing at 
first. Although the manual helped ac¬ 
climate me by offering good examples 
and an excellent introduction, the 
learning curve was long and steep. 

Actor has fully integrated the edi¬ 
tor, debugger, and execution environ¬ 
ments. You start off in the browser 
window creating object classes (for 
those unfamiliar with the concept, 
think of them as data structures) and 
the methods (procedures to manipu¬ 
late the structure) used by those class¬ 
es. As soon as you have enough of 
your application done, you can invoke 
it from the workspace window and be¬ 
gin testing and debugging. You can 
then switch back to the browser to 
add more methods and classes. It’s 
not even necessary to have coded out¬ 
put functions. You can use an inspec¬ 
tor to look at the instance variables 
(elements of the data structure) of the 
objects to make sure that they are cor¬ 
rect. All program changes are stored 
in a work directory under the main 
Actor directory. When you save your 
work (called taking a snapshot), the 
contents of this temporary directory 
are copied to the classes directory. If 
you do not save your work, you can 
have it reloaded the next time you en¬ 
ter Actor. This lets you have a work¬ 
ing copy and a development copy at 
the same time — and lets Actor keep 
them straight. Since all changes are 


saved in the work directory, it also 
means that Actor can recover if your 
system crashes. 

The browser window has four pan¬ 
els. One displays a list of objects in 
the system; another displays all in¬ 
stance variables for the selected ob¬ 
ject. The third shows all methods for 
the selected object; the fourth (and 
largest) shows the text for the selected 
method. A browser window can dis¬ 
play only one method at a time, but 
you can open several windows to view 
related methods for the same or dif¬ 
ferent classes. 

One of the most powerful features 
of object-oriented programming is in¬ 
heritance. A decedent object inherits 
all the instance variables and methods 
from all its ancestors. It can, of 
course, redefine any that need to be 
changed to handle the object’s special 
needs, like initialization. I found this 
aspect of object-oriented program¬ 
ming the most difficult to get used to, 
not because the concept is that hard 
but because some things were so 
transparent I couldn’t figure out how 
to do them. For instance, Windows 
sends a WM_Move message when the 
mouse is moved, and I wanted to han¬ 
dle that in an application. But, at the 
time, I didn’t know what message 
Windows sent, and I had a heck of a 
time figuring it out. Because the mes¬ 
sage is normally handled as part of the 
Windows object, it normally doesn’t 
appear in application code. The 
browser window has two functions 
that help solve this problem. You can 
select a message name and determine 
which classes and methods implement 
or send that message. I found this very 
useful when looking for examples 
within Actor for how it does things. 
The source code for most Actor class¬ 
es can be displayed in the browser. 

You can build dialogue boxes and 
menus by using the Whitewater Re¬ 
source Toolkit included with the 
package or by using Actor methods. 
The toolkit is a graphical tool that 
also creates icons, bitmaps, strings, 
and accelerator keys. However, con¬ 
necting resources to the application is 
not as well documented as it could be. 

The ObjectGraphics library of class¬ 
es and methods also comes with the 
program. I didn’t use it, but it appears 
very extensive, with classes and meth¬ 
ods for manipulating bitmaps, brush¬ 
es, colors, cursors, and text. 

Debugging in Actor is a pleasure — 
or at least as pleasurable as debugging 
can be. In the event of a runtime er¬ 
ror, you are presented with a stack 
trace showing all methods in execu¬ 
tion. Selecting the debug button 


brings up the debugging browser, 
where you can look at the source for 
all methods on the stack and also que¬ 
ry the methods’ temporary and in¬ 
stance variables for any classes used. 
You can correct any errors in a meth¬ 
od or the values of variables, and then 
resume execution from the point of 
the error. 

The only thing the debugger doesn’t 
do is identify the current line in each 
method on the stack. There is also no 
way to set breakpoints. However, I 
discovered that intentionally creating 
a runtime error that I corrected from 
the debugger worked almost as well. 

During development you use an 
Actor image file, which contains an 
image of your work in progress, in¬ 
cluding the contents of all windows. 
The Actor .EXE file reads the image 
file to set up your work environment. 
When your application is complete, 
you can create a modified version of 
Actor. This version can read only the 
image file associated with your appli¬ 
cation. Your application then consists 
of the modified .EXE file and the im¬ 
age file. 

The company offers three forms of 
support with this $495 package. I used 
a 30-day-free plan and was not really 
satisfied with it. Most of the time I 
was placed in a voice mail system that 
instructed me to leave my name, num¬ 
ber, and a summary of the problem 
and told me someone would get back 
to me. Sometimes they did, sometimes 
they didn’t. When I finally spoke with 
someone, I found the response helpful. 

Actor is a large, complex language 
and environment with a very long and 
steep learning curve. However, it has 
enough power to make climbing that 
curve worthwhile for anyone who 
writes large, complex applications. 

Readers can contact the Whitewa¬ 
ter Group Inc. at 1800 Ridge Ave., 
Evanston, IL 60201; (708) 328-3800; 
or circle Reader Service Number 24. 


Smalltalk/V for Windows 1.1 

My exposure to Actor jump-started 
me for Smalltalk, since both use ob¬ 
jects, inheritance, methods, and mes¬ 
sages, and have a very similar devel¬ 
opment environment. The manual, 
however, does not assume that you 
are familiar with the object-oriented 
environment and provides a good tu¬ 
torial. The development disk also pro¬ 
vides some excellent examples. In ad¬ 
dition, because Smalltalk has been 
around for over 15 years, a number of 
good books describe how to use it, al- 
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though none discusses the Windows 
environment. 

Except for taking up at least 3 
Mbytes of memory, Smalltalk’s re¬ 
quirements are not unreasonable. 
However, I found my system sluggish 
both when loading and exiting Small¬ 
talk or when switching between a 
Smalltalk window and another appli¬ 
cation’s window — even on my 4- 
Mbyte 33-MHz 386. The Smalltalk en¬ 
vironment, however, is quite fast. 

The first part of the Smalltalk man¬ 
ual is a description of Smalltalk and a 
tutorial. The tutorial programs includ¬ 
ed on the distribution disk are easy to 
run and experiment with. Despite the 
jump-start I got from Actor, I found 
the tutorial helpful. The second part 
of the manual describes Smalltalk 
classes and the Windows environ¬ 
ment. It did this well but was weak in 
describing how to connect the two by 
creating windows and dialogue boxes. 
The distribution disk includes some 
examples that helped a lot, but some 
things like window styles are not de¬ 
scribed anywhere. When I called tech¬ 
nical support, I learned that I was ex¬ 
pected to have the Windows Software 
Development Kit (SDK), which in¬ 
cludes this kind of documentation. 

The one thing that Smalltalk does 
not have is a resource-building tool. 
Creating a dialogue box or a menu is 
done via methods that build the dia¬ 
logue or menu one control at a time 
during execution. 

Smalltalk and Actor both display 
several browser windows with the 
same format and allow an iterative ap¬ 
proach to building an application. In 
fact, a quick glance at the screen does 
not help distinguish one from the oth¬ 
er. The big difference I saw in the 
$495 Smalltalk package is that it pro¬ 
vides better debugging information. It 
shows you where in the method you 
are when you display the stack. You 
can also set breakpoints at the start of 
any method. 

Another difference is the way .EXE 
files are created. Smalltalk is com¬ 
posed of two .EXE files, vw and v, 
and a number of dynamic link librar¬ 
ies. All of the classes and methods are 
placed in the v.exe file, which you can 
rename and distribute as your applica¬ 
tion along with most of the DLL files. 
However, since all your classes and 
methods are in the v.exe, if you are 
working on two applications at the 
same time, both will be in the file. 

You have to manually remove the 
classes for one application before re¬ 
naming the file to create the .EXE for 
the other application. The alternative 
is to create separate v.exe files and 
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juggle them based on which applica¬ 
tion you want to work with before you 
start Smalltalk. 

I found that sometimes when I 
switched between my Smalltalk appli¬ 
cation and others, my system hung, or 
the Smalltalk application generated a 
UAE and then my system would hang. 
Several times 1 also got a UAE error 
when I loaded the Smalltalk environ¬ 
ment. I was forced to reload Smalltalk 
from the distribution disk. I probably 
did something that caused the prob¬ 
lem, but I don’t think this should have 
been possible. 

The technical support at Digitalk 
was very good. I almost always got 
through to someone within a minute 
or two, and they were always helpful. 

I really wanted to like Smalltalk, 
and the easy debugging and excellent 
technical support helped. However, I 
think that a 3-Mbyte memory require¬ 
ment is excessive for a general-pur¬ 
pose application. I also had just too 
many troubles with UAE errors — 
both in the development environment 
and when running applications — to 
make it my environment of choice. 

Readers can contact Digitalk at 
9841 Airport Blvd., Los Angeles, CA 
90045; (213) 645-1082; or circle Read¬ 
er Service Number 25. 


Borland C++ 2.0 

Borland C++ is a superset of 
AT&T’s C++. While it provides all 
the properties of an object-oriented 
language (including multiple class 
inheritance, something that neither 
Actor nor Smalltalk has), the built-in 
classes are limited. Although Borland 
C++ is not a Microsoft Windows ap¬ 
plication, it does allow you to create 
windows applications. It replaces the 
MS Windows SDK with its own set of 
routines and libraries. However, the 
end result is a programming environ¬ 
ment that is every bit as difficult to 
learn and work in as Microsoft’s SDK 
environment. 

Before you even load C++ onto 
your system, the number of manuals 
included in the package gives you an 
idea of its complexity. There are five 
C++ manuals, and debugger, assem¬ 
bler, and profiler manuals. Only small 
portions of the manuals deal with cre¬ 
ating an MS Windows application, 
and there is no discussion of any of 
the necessary routines. Borland’s 
technical support told me to get the 
SDK documentation and read some of 
the numerous books on programming 
for the MS Windows environment. 

Installing C++ is fast and easy, but 


you’ll need lots of free disk space. It 
took up almost 15 Mbytes on my sys¬ 
tem. You can recover a lot of that 
space by deleting libraries, examples, 
and utilities that you don’t need. 

There are several ways to create 
programs with Borland C++. It has 
command-line-oriented Make, Com¬ 
piler, and Linker commands and 
something called the IDE, or integrat¬ 
ed development environment. The 
package also has real- and protected- 
mode versions of these commands. 
However, you cannot run the protect- 
ed-mode versions in a DOS window if 
you are running MS Windows in en¬ 
hanced mode. I also discovered that 
the IDE in real mode was limited to 
very small programs. Even the moder¬ 
ate-sized Windows examples got an 
“out-of-memory” error. Because I 
normally run in enhanced mode, I was 
forced to exit Windows to run the 
IDE in protected mode. After I creat¬ 
ed the .EXE file, I had to restart Win¬ 
dows to test it. 

The IDE itself runs in text mode, 
but it “does Windows” and is mouse 
sensitive. Each window has a zoom- 
and-close box, and a vertical and hori¬ 
zontal scroll bar. You can have multi¬ 
ple files open at the same time and 
switch between them with a click of 
the mouse or a few keystrokes. You 
can also cut and paste between win¬ 
dows. The IDE uses something called 
a project to keep track of all files 
needed to create an application. You 
can rebuild the application’s .EXE file 
with just a menu selection. 

The project concept was the main 
reason that I didn’t use the command 
environment. The command-line com¬ 
piler has over 100 control arguments, 
and the linker has 25. Then there is 
Make, which is derived from the Unix 
make command. Make keeps track of 
the files needed for an application and 
calls the compiler and linker as neces¬ 
sary. However, you must create and 
maintain the Make file. I have always 
found all its options and syntax con¬ 
fusing. The project concept and the 
settings defined in the IDE take care 
of this for you; all you have to supply 
are file names. 

As stated, I found building Win¬ 
dows applications very complex. A 
few examples helped somewhat (I 
built on them to create my own appli¬ 
cations), but the lack of Windows doc¬ 
umentation caused problems. Also, 
C++ has nothing like the browsers in 
Actor and Smalltalk for looking at dif¬ 
ferent classes and methods. Perhaps 
that is because C++ has so few built-in 
classes. I had to build classes for al¬ 
most everything. The only thing that 
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C++ included was header files for all 
the Windows objects that you need. 

There are two ways to build dia¬ 
logue boxes with this $495 package. 
The first is to use calls equivalent to 
the SDK calls for building a dynamic 
dialogue box. However, as I said, no 
documentation is offered for doing 
this. The second way is to use the 
Whitewater’s Resource Toolkit in¬ 
cluded in the package. 

The Turbo Debugger also operates 
in text mode, but it only allows you to 
debug your windows application when 
you are using a standard video driver. 
If you are using a Super VGA driver 
— even just a 640 x 480 x 256 — when 
you switch back from the Turbo De¬ 
bugger screen, the Windows screen is 
scrambled. 

The debugger provides a lot of flex¬ 
ibility. You can set breakpoints at any 
point in your program. You can even 
set conditions to be evaluated at the 
breakpoint, with the break being exe¬ 
cuted only if the condition is true. 

You can also display and change the 
contents of variables. You can log 
messages that Windows sends to your 
program. It is basically one of the best 
debugging environments that I have 
seen, but, like Borland C++, it’s not 
easy to learn to use. 

Borland’s technical support was 
good once I got to it, but I experi¬ 
enced several 5-to-10 minute periods 
on hold. You have to get through a 
four-level touch-tone menu system 
before you can ask for support. 

Overall, I was disappointed in Bor¬ 
land C++. The impression I got was 
that this is really C with a very thin 
veneer of object orientation, and 
while it’s true that the package pro¬ 
vides the tools needed to build a Win¬ 
dows application, they are hand tools 
rather than power tools. 

Readers can contact Borland Inter¬ 
national at 1800 Green Hills Rd., PO 
Box 660001, Scotts Valley, CA 95067; 
(408) 438-5300; or circle Reader Ser¬ 
vice Number 26. 


KnowledgePro (Windows) 
Gold 1.1 

KnowledgePro differs from the oth¬ 
er environments reviewed here. If 
anything, it’s vaguely reminiscent of 
Lisp. This is not surprising, because it 
comes from an AI environment and 
retains functions like backward chain¬ 
ing. A quick reading of the manual 
and a look at the examples might lead 
one to think that KnowledgePro is a 
specialized environment for creating 
hypertext documents. Indeed, it con- 


Updates 

Since I received and reviewed 
these packages, several facts have 
changed. Matesys Corp. is ship¬ 
ping version 1.04 of ObjectScript 
Pro. This, I am told, is a much- 
improved, enhanced version of 
ObjectScript with features that in¬ 
clude printer support and a report 
writer. The documentation has also 
been completely rewritten. Object- 
Script Pro costs $499 but comes 
with an unlimited user license for 
$899. The version of ObjectScript 
reviewed here is still available for 
$150. 

I have also been told that Bor¬ 
land is preparing a Windows-based 
version of Borland C++. I have no 
details on its availability, price, or 
features. 

Finally, Knowledge Garden has 
announced a graphics package for 
KnowledgePro that lets you draw 
objects in a window. 


tains many functions designed to al¬ 
low easy creation of hypertext docu¬ 
ments. However, KnowledgePro is a 
general-purpose language that you 
can use to create almost any kind of 
Windows application. 

The $595 KnowledgePro develop¬ 
ment environment consists of an edit¬ 
ing window with a menu bar contain¬ 
ing editing, compiling, and debugging 
functions. The editor is very similar to 
the Window’s Notepad editor, with 
the addition of “replace” and “goto 
line” options in the edit menu. When 
you open several source files at the 
same time, they are displayed in child 
windows that can be overlapped or 
tiled. KnowledgePro source files are 
called knowledge bases and have the 
suffix KB. Compiled knowledge bases 
have the suffix CKB. 

The foundation of the Knowledge- 
Pro language is something called a 
topic. At first glance, a topic looks like 
a procedure. It’s defined with a name 
and an optional list of parameters en¬ 
closed in parentheses. The code that 
follows a topic definition is executed 
when the topic is invoked by including 
its name in the code of another topic. 
However, a topic doesn’t need param¬ 
eters or code to execute; it can just be 
assigned a value to make it look like a 
variable. 

There are no data types in Knowl¬ 
edgePro. Data is stored as strings, and 
the type of string — numeric or alpha¬ 
numeric — is determined from its con¬ 
tents. The package has only one type of 
data structure: a list. Lists, of course, 


can contain sublists, and the program 
has many functions for the manipula¬ 
tion of lists and their elements. 

The package contains two very in¬ 
teresting features. First, “demon” top¬ 
ics can be used to automatically vali¬ 
date changes in the values of other 
topics. Each demon topic is associated 
with a target topic. When the value of 
the target topic is changed, the demon 
topic is called. The demon topic can 
validate the new value and allow the 
change to take place, or it can substi¬ 
tute a different value. 

The second noteworthy feature is 
that strings can be evaluated and exe¬ 
cuted like code. Unfortunately, this 
feature is only available in the devel¬ 
opment version of KnowledgePro (the 
runtime version reports an error). 

This package has one limitation: its 
graphics functionality. You can only 
display a rectangular bitmap - and 
you can’t draw in a window. Also, 
while you can set up a hyperregion 
covering the window so that a mouse 
click anywhere in the window causes 
the row and column of the mouse lo¬ 
cation to be sent to a topic, you can’t 
track mouse movements across the 
application window. 

While KnowledgePro is not overtly 
object-oriented, the functions “new” 
and “im_a” and the capability to cre¬ 
ate nested topics let you treat topics 
as objects and program within the ob¬ 
ject-oriented paradigm. The subtopics 
containing code are equivalent to the 
object’s methods; the subtopics con¬ 
taining just values are equivalent to 
instance variables. The program al¬ 
lows multiple inheritance simply by 
including multiple im_a statements in 
the topic definition. This is not pure 
object programming. For instance, the 
“variables” of an “object” can be ref¬ 
erenced by other “objects,” and you 
must indicate which “object” a “meth¬ 
od” is in to execute it. Still, the inher¬ 
itance feature is useful, and by stick¬ 
ing to the rules of object-oriented 
programming, you can derive most of 
its benefits. 

The KnowledgePro environment is 
very easy to work in. After creating a 
knowledge base, all I had to do was se¬ 
lect Go from the menu bar to compile 
and execute it. Syntax errors were re¬ 
ported, but most of the program still 
executed. The Debug option on the 
menu bar gave access to the topics in 
the currently running knowledge base. 

I could display and alter the values of 
any topic. The only thing the debugger 
couldn’t do was set a breakpoint. But I 
found that I could create a pseudo¬ 
breakpoint programmatically by in¬ 
cluding a wait statement in the code. 
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This causes the program to wait until a 
“continue” button is pressed. 

I had no trouble building menus 
and dialogues for my test applications. 
These and all screen objects are con¬ 
structed dynamically via calls to func¬ 
tions that provide complete control 
over all object attributes. Unlike most 
other environments where you posi¬ 
tion objects via pixel coordinates, 
KnowledgePro lets you position ob¬ 
jects via character coordinates using 
the size of the system font. This makes 
screen layouts independent of the 
screen resolution. Factional coordi¬ 
nates can be used to place an object 
anywhere in a window. 

The KnowledgePro Gold distribu¬ 
tion kit includes a runtime version that 
can be distributed royalty free with 
your application. An application con¬ 
sists of the compiled form of a knowl¬ 
edge base and an optional icon file that 
can be attached to the application win¬ 
dow so that it has its own icon. If you 
don’t need the runtime version, you 
can purchase KnowledgePro instead of 
KnowledgePro Gold. 

Company support was excellent. I 



had no trouble getting in touch with 
technical support, who answered all 
questions quickly and accurately. 

The more I use KnowledgePro, the 
more I like it. I easily created my test 
applications and had no difficulty in¬ 
terfacing with Windows. For applica¬ 
tions not requiring graphics, this is an 
ideal environment. 

Readers may contact Knowledge 
Garden Inc. at 473A Malden Bridge 
Rd„ Nassau, NY 12123; (518) 766- 
3000; or circle Reader Service Num¬ 
ber 27. 


Summary 

Which environment am I going to 
use for my next application? Since the 
application I have in mind is a simple 
birthday-reminder system, I will use 
KnowledgePro. I also have plans for 
a graphics-based application; my 
choice for it will be Actor. Finally, 

I keep a checking-account summary 
in a spreadsheet, but it doesn’t do ev¬ 
erything the way I want it to. I think 
I’ll try using Realizer and its spread¬ 
sheet tool to create a perfect check¬ 
ing-account program. 

Someone once told me that the dif¬ 
ference between a professional and an 
amateur is that the professional al¬ 
ways has the right tool for the job 
(and knows how to use it). The tools 
of a programmer are programming 
environments, and while none of 
these languages is ideal for all types of 
programming projects, I think Realiz¬ 
er, Actor, and KnowledgePro are the 
best in their respective domains. 


Review note 

The Painless Event Processor. PEP 

is an easy way to automate your rou¬ 
tine computer tasks. The program is 
functionally equivalent to the “cron” 
utility available with most Unix sys¬ 
tems. PEP, however, is available for 
DOS and runs within 256 Kbytes. 

The package lets the user create 
script files that can be scheduled to 
run at any time. The scripts contain 
events — usually programs or batch 
files — specified by the user. The 
scheduling information can be a single 
execution at a given date and time, or 
multiple executions at a fixed interval. 
The interval can be daily, weekly, 
monthly, or annually, with fixed exe¬ 
cution within the given span. 


Within the PEP main program, one 
can key in and edit the script files. 
When the script files are edited, they 
can be stored on disk. The scripts can 
contain any character or characters 
that can be keyed in. These strings of 
characters are shown as metacharac¬ 
ters, and all keyboard keys are valid, 
including spaces and carriage returns. 
The resulting scripts are keyboard 
emulations that replace the keyboard 
driver. Therefore, the scripts can con¬ 
tain not only the commands for the 
DOS prompt but also commands for 
use within the executed program. 

The scripts are saved in files. A 
TSR program called PERecorder eas¬ 
es input. You can exit to the recorder 
program from the main program by 
turning on a keyboard trace facility to 
monitor the keyboard. With the key¬ 
board monitor, you run the programs 
to be executed. When complete, the 
traced keys can be saved in a file for 
use as a keyboard script. 

An event file contains all events 
necessary for executing the keyboard 
scripts. You use the event editor in 
the main program to specify which 
script files to execute, and when and 
how often to execute them. Up to 
eight events can be specified per file. 

When the script and event files are 
specified, the user schedules the 
events. To do this, you load the event 
scheduler (PEScheduler) from the 
main program or the DOS prompt. 
Either way, a TSR program is loaded 
with the specified event file. You can 
make the program part of your 
AUTOEXEC.BAT to automate pro¬ 
cess execution. 

At the specified time, a pop-up 
menu tells the user that the PESched¬ 
uler is ready to execute a script. This 
menu contains the script file name 
and a clock that starts at one minute 
and counts down to completion with¬ 
out user intervention. This gives the 
user enough time to complete the cur¬ 
rent task and prepare for execution of 
the keyboard playback file. The user 
can abort the event execution or re¬ 
quest immediate execution when the 
system is ready to process the script. 

In all, PEP is a handy tool for task 
automation. Although not a new idea, 
it’s definitely the best mechanism I 
have seen for solving this particular 
problem on an MS-DOS system. 

Painless Event Processor is avail¬ 
able from Painless Accounting for 
$45. Readers can contact the company 
at 4401 Birdsong, Plano, TX 75093; 
(214) 596-9164; or circle Reader Ser¬ 
vice Number 28. 

— Ed Gordon, Bdata Systems 
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A massive show of supercomputing 


E = MC 2 

The Cray Y-MP C90 supercomputer 
has 16 new CPUs and operates at four 
times the speed of the company’s pre¬ 
vious fastest computers. Each CPU 
has a peak performance of 1 Gflops; 
with 2 Gbytes of central memory, 16 
CPUs reach 16 Gflops. 

The C90 is fully upward compatible 
with other company products and fea¬ 
tures a dual-vector pipeline that al¬ 
lows each CPU to deliver two vector 
results per functional unit per clock 
period. 


The liquid-cooled system also fea¬ 
tures autotasking software that por¬ 
tions a problem across multiple CPUs, 
four double-width memory ports per 
CPU, and more than 250 Gbytes/s of 
memory bandwidth. Aggregate I/O 
bandwidth reaches 13 Gbytes/s with 
up to 16 I/O clusters. Users can direct¬ 
ly attach 4 Tbytes of disk storage. 

An optional solid-state storage de¬ 
vice provides very high speed second¬ 
ary memory with up to 16 Gbytes of 
storage capacity. A bandwidth of 


7,200 Mbytes/s to the mainframe sup¬ 
ports the solution of large problems. 

New technologies include custom 
high-speed 10,000-gate-array circuits 
with four times the integration of pre¬ 
vious devices, surface-mount compo¬ 
nent assembly to reduce problems 
associated with chip leads, and multi¬ 
layer circuit boards with internal path¬ 
ways to protect from contaminants. 

The C90 costs $30.5 million. 
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Ncube development 


Virtuous modularity 


Ncube has announced the Parallel 
Software Environment Unix-based 
development system for Ncube 2 su¬ 
percomputers. The programming 
model is based on System V Release 4 
and includes MIMD and SPMD (a su¬ 
perset of SIMD) architectures. 

Compilers are built on ANSI C, 
C++, and Fortran with VAX exten¬ 
sions. Standard I/O calls operate in 
parallel transparently. Software li¬ 
braries for backward compatibility let 
users upgrade. 

The environment is scheduled to 
ship this month. 
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Multibus machine 


The Meteor Multibus II parallel su¬ 
percomputer from Mentec Computer 
Systems features scalable perfor¬ 
mance from one to 16 i860 processors 
and delivers 40 to 500 MIPS. Scalabili¬ 
ty comes in one-processor increments. 

Accessible from existing LANs, Me¬ 
teor supports DEC, Sun, 386, and 
Macintosh graphical front ends. It also 
features compliant Opal, Tuplex, C- 
Linda tools, ANSI C, and Fortran 
programming languages. 

Reader Service Number 36 


The Paragon XP/S from Intel can 
hold over 1,000 i860 XP microproces¬ 
sors that each run at 42 MIPS and 75 
double-precision Mflops while op¬ 
erating at 50 MHz with a 20-ns clock 
cycle. Floating-point unit-to-cache 
bandwidth peaks at 800 Mbytes/s. An 
additional XP in each node is dedicat¬ 
ed solely to communications process¬ 
ing. 

The Paragon is scalable from 5 to 
300 Gflops and 2.8 to 160 KMIPS. The 
Unix operating system is based on a 
MACH microkernel combined with 
OSF/1 server technology. Each Para¬ 


gon processor is fully compatible with 
Intel’s iPSC/860. 

The Paragon system has up to 128 
Gbytes of main memory. Multiple Hip- 
pi channels have 100-Mbyte/s band- 
widths. Languages include C, C++, 
Fortran, and data-parallel Fortran. 

Visualization capabilities use the X- 
Window System, the Distributed 
Graphics Library, and the Advanced 
Visualization System. 

The Paragon starts at under $2 mil¬ 
lion. 
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Big man on campus 


Alliant Computer Systems has in¬ 
troduced the CAMPUS/800 massively 
parallel processing supercomputer 
with up to 800 RISC processors. The 
system supports both distributed and 
shared memory for coarse- and fine- 
grain parallelism. 

A fully configured CAMPUS con¬ 
sists of 32 nodes holding a cluster of 
25 Intel 64-bit i860 RISCs and 4 
Gbytes of high-speed shared memory. 
Performance peaks at 32 Gflops with 
128 Gbytes of memory. The nodes 


Entry-level Convex 

The C3400-ES supercomputer con¬ 
tains CPUs, memory, and peripherals 
in a 19-inch RETMA rack cabinet. 
Configurable with one or two proces¬ 
sors, up to 512 Mbytes of memory, 
and 4 Gbytes of virtual memory, the 


Parallel accelerator 

IBM has announced a development 
capability and program expanding the 
use of parallelism for supercomputing 
on the Enterprise System/9000. Using 
company RISC technology integrated 
into the ES/900 or ES/3090 complex. 


After the computations 

The E-Systems Modular Automated 
Storage System (EMASS) is a family 
of computer-controlled robotic data¬ 
storage and retrieval systems with a 
modular storage range of 0.5 to 10,000 
Tbytes. The company claims average 
access time to data volumes is less 
than 30 seconds and that data transfer 
rates are 15 Mbytes/s, or up to 10 
times faster than other mass systems. 

EMASS stores data on small, medi¬ 
um, and large 19-mm cassettes and 
3480-compatible tapes. A small car¬ 
tridge (about the size of a Beta VHS) 
reputedly holds 25 Gbytes of data, a 


Deskside supercomputing 

The Zephyr “deskside” massively 
parallel system from Wavetracer 
works with most Unix workstations 
and weighs less than 80 pounds. Mod¬ 
els 4 and 8 contain 4,096 and 8,192 
processing elements and 128 and 256 
Mbytes of memory respectively. 

According to the company, Model 8 


communicate over a 2.56-Gbytes/s 
high-speed memory interconnect. 

Development tools include the 
company’s automatic parallel compil¬ 
ers and libraries, and the Express en¬ 
vironment from ParaSoft Corp. Other 
standard tools include TCGMSG and 
P4 from Argonne National Laborato¬ 
ry and PICL from Oak Ridge National 
Laboratory. The machine is compatible 
with the applications developed for the 
FX/2800 supercomputer. 

Because a fully functioning Unix 


ES operates on 220V single-phase 
power at a peak rate of 200 Mflops. 

A bundled configuration includes 
disk and tape subsystems, network 
connections, and system and compiler 
software. The system can operate as a 


the Integrated Parallel Accelerator 
comes in two configurations. 

The 16-node Model 021 includes an 
integral ES/9000 and peaks at 1.3 
Gflops; the 60-node Model 020 incor¬ 
porates selected ES/9000 and ES/3090 


medium one up to 75 Gbytes, and a 
large, up to 150. The company’s Data- 
Tower hardware storage module for 
use with EMASS can hold 6 Tbytes. 
The DataLibrary stores 28 Tbytes by 
linking four DataTowers, with a total 
capacity of up to 10,000 Tbytes. 

E-Systems has also released 
FileServ software, which operates as 
an adjunct to the host platform’s ex¬ 
tended native Unix file system. It 
monitors user-specified file directories 
and manages file transfers between 
tape and disk transparently. 

When directing the operation of a 


reaches more than 700 million opera¬ 
tions per second and processes a 10K 
x 10K image in 34 minutes. 

The system uses standard 110V, 7- 
amp power and works transparently 
with Unix workstations from IBM, 
Sun Microsystems, Silicon Graphics, 
and Sony. Interfaces for Apple and 


operating system executes on each 
node, the CAMPUS system can sup¬ 
port simultaneous execution of com¬ 
putational tasks with Unix file I/O, 
network activity, and development. 

Product availability is scheduled for 
the second quarter of 1992. The sys¬ 
tem starts at $2.5 million for a typical 
configuration with 100 processors. 
Upgrades for current FX/2800 systems 
start at under $100,000. 

Reader Service Number 39 


server and contains both custom 
BiCMOS gate arrays and GaAs cir¬ 
cuitry. 

Pricing starts at $295,000. 

Reader Service Number 40 


processors peaks at 4.8 Gflops. 

Enhanced Clustered Fortran and an 
extended mainframe Aix operating 
system support the Inpac facility. 
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fully configured automated cartridge 
system, FileServ provides access to 1.2 
Tbytes of data storage on 6,000 3480- 
compatible magnetic tapes. Multiple 
ACS unit management can expand ca¬ 
pacity to over 19 Tbytes. The software 
can access files through Ethernet, 
DECnet, FDDI, Hyperchannel, and 
UltraNet interfaces. According to the 
company, FileServ conforms to the 
IEEE standard mass-storage model. 

Prices vary according to data stor¬ 
age needs. 
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Hewlett-Packard systems are under 
development. 

The Zephyr Model 4 costs $85,000; 
Model 8 is $150,000. Volume pricing is 
available to systems integrators and 
software-oriented VARs. 
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On the Mac 


Draw in 3D 

The Sketch! design program from 
Alias Research lets users draw free¬ 
form curves and surfaces in 3D space, 
including 2D planes or 3D surfaces. 
The package uses NURBS (nonuni¬ 
form rational B-spline) mathematics to 
provide exact descriptions of points. 

Users can draw in perspective on 
existing images such as an imported 
PICT file. The Curve-o-matic tool lets 
users automatically draw accurate 3D 
curves consisting of combinations of 
spline curves, arcs, or straight lines. 
An intuitive eraser lets users rub out 
portions of a curve. 

Image-rendering features range 


Point-and-click waveforms 

The SuperScope waveform acquisi¬ 
tion package from I/Otech features an 
on-screen virtual front panel that lets 
users access functions through a Mac¬ 
intosh point-and-click interface with¬ 
out programming. It provides 45 analy¬ 
sis functions and displays up to eight 
defined waveforms simultaneously. 

Users can employ a mouse to ma¬ 
nipulate data displayed on the virtual 


from flat shading to high-resolution 
photorealism. Rendering is performed 
in the background. 

The program has bidirectional links 
to 2D via PICT and EPSF formats 
and a direct link with Adobe illustra¬ 
tor. Designs can be exported to a vari¬ 
ety of CAD packages and worksta¬ 
tion-based CAID systems. 

Sketch! runs on Macintosh II and 
Quadra computers using System 6.0.5 
or higher with 5 Mbytes of RAM and 
40 Mbytes of available disk space. 

The program costs $1,995. 
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panel and edit tabular waveforms in 
a spreadsheet environment. An inte¬ 
grated word processor and lab journal 
let users design reports with text and 
graphics. Eleven postprocessing mod¬ 
ules automatically perform such tasks 
as pulse analysis and data transfer. 

The package costs $995. 
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Plots on a Plus 

SigmaPlot from Jandel Scientific 
now supports standard Mac interfaces 
and System 7.0 software. (It will run 
with System 4.2 or greater on a Mac 
Plus with 1 Mbyte of RAM.) 

Users can choose from graph types 
that include scatter and line graphs, 
vertical and horizontal bar charts, 
tacked bar charts, box plots, step 
plots, histograms, quality control 
graphs, and pie charts. Specialized 
axis scales include linear, semilog, log- 
log, natural log, probability, probit, 
logit, and reverse scales. 

Users can adjust intervals, tick 
marks, and grids and define line thick¬ 
ness and type, colors, fill patterns, and 
symbols. Error-bar types include stan¬ 
dard error, standard deviation, and 
95- or 99-percent confidence levels. 
Calculations are based on arithmetic 
or geometric means. 

A 32,000-row-by-16,000-column 
data worksheet supports a range of 
mathematical functions. Users can ac¬ 
cess descriptive statistics and Mests 
from within the worksheet. 

The package costs $395. 
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Fast floating point 

Running on System 7.0 Macintosh 
Quadra 700 and 900 computers, Lab- 
View 2.2 software reduces the time re¬ 
quired to analyze data by generating 
in-line floating-point instructions. 
Simple calculations execute about 
twice as fast as those on a Mac Ilfx, 
analysis functions execute about 3.5 
times faster, and graphing functions 
execute about 1.5 times as fast. 


The National Instruments software 
features an icon-based graphical pro¬ 
gramming language and compiler with 
front panels and block diagrams for 
software development. Data can be 
acquired from GPIB, VXI, or RS-232 
instruments . 

The package costs $1,995. 
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LabView 2.2 for 
the Macintosh 
features table, 
custom PICT 
slide, and alarm 
slide controls. 



With an eye for applications 

TGS Systems has introduced Pro¬ 
graph Version 2.5, a visual program¬ 
ming environment for the Macintosh 
that supports System 7.0 interapplica¬ 
tion communications and provides a 
database engine. Prograph connects to 
SQL databases through DAL and Or¬ 
acle interfaces. 

The object-oriented environment 
includes a code compactor that reduc¬ 
es Prograph methods to 25 percent of 
their original size. The database en¬ 
gine lets developers create databases 
that accommodate textual, numeric, 
picture, and icon data types. It also 
supports multiple tables per database, 
indexed key access with multiple keys 
per table, and multiuser access. Appli¬ 
cations can be flat file, relational, or 
object-based. 

The package operates with a parti¬ 
tion size of 1.5 Mbytes of RAM; is 
compatible with 6.0, 7.0, and A/Ux 
systems; and costs $495. Prograph 2.0 
users can upgrade for $49.99. 
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1C Announcements 


R.S. No. 


Burr-Brown 
DAC2815, DAC4815 
Digital/analog 
converters 


Dual and quad D ACs with 2-byte (8+4) double-buffered parallel interfaces. D AC2815 
needs no external components for either unipolar 0 to 10V, 0 to -10V, or +10V output 
ranges; D AC 4815 requires no external components for the bipolar 10V output range. Key 
specifications include 12-bit resolution, lOpsec (max) and 3.5 psec (typ) settling times. 
Offered in 28-pin plastic DIP. Cost (in 100s): $16.95 (DAC2815); $24.95 (DAC4815). 


Cirrus Logic Intelligent modem device set provides complete data, fax, and voice capabilities in two ICs 

CL-MD1424 that eliminate requirements for external controller, host interface, memory, and associated 

Modem chip set components. Full-duplex data communication up to 2,400 bps and facsimile up to 14,400 bps. 

Voice mode allows a PC to emulate a telephone-answering machine. Cost (in 1,000s): $45. 


Crosspoint Solutions First fully compatible field-programmable replacements for standard mask-programmable 

CP20K Series gate arrays. Transistor-level interconnect programmability results in gate-level granularity 

FPGAs with standard MPG As. Sample quantities now available for CP20420, with 4,245 available 

gates and 130 I/O pads. Cost (in 100s): $277.70. 


Fujitsu Microelec¬ 
tronics 
MB89372A 
Controller 


New data communications controller supports multiple standard protocols and encoding 
schemes. Other features include four-channel direct memory access and two full-duplex 
serial interface units on chip. Maximum transfer rate is 2Mb/sec. Packaged in 64-pin plastic 
shrink DIP, 64-pin plastic QFP, and 68-pin plastic LCC. Cost (in 10,000s): $12.75. 


Linear Technology Current-feedback, DC-coupled, operational amplifiers feature bandwidth of 100 MHz, 

LT1229/LT1230 slew rate of 1,000 V/psec, settling time (10V to 0.1 percent) of 45 nsec, minimum output drive 

Dual/quad amplifiers current of 30 mA, and input noise voltage of 6nV//Hz. Suitable for video and automatic test 

equipment applications. Cost (in 100s): from $3.95 (LT1229) and $7.25 (LT1230). 


Mark Eyelet Precision cold-formed pin grid arrays use exclusive Omni-Tact seamless, BeCu, low-inser- 

Series MD tion-force, 4-tyne contacts. Can be used interchangeably with screw machine devices. 

PGA sockets Manufactured in five popular grid sizes. Cost (in high-volume quantities): from $0.01/ line. 


Mips Computer Systems Third-generation implementation of the Mips RISC architecture provides full binary com- 
R4000 patibility with its predecessors and full 64-bit technology and multiprocessing capabilities. 

Microprocessor chip Runs at 50 MHz. PC version supports primary on-chip cache; SC version provides secondary 

cache; and MC version provides secondary cache and multiprocessing features. 


Samsung Semicon¬ 
ductor 
KM424564, 
KM424C256 
Video RAMs 


High-performance video RAMs combine a conventional DRAM array with a serial-access 
memory (SAM) in a dual-port architecture and speed system performance by off-loading 
screen refresh from the main data bus. KM424564 is a 256-Kbit device available with access 
times of 100 and 120 nsec; KM424C256 is a 1 -Mbit device available with access times of 80, 
100, and 120 nsec. Cost (in 1,000s): $3.10 (KM424C64,100 nsec); $8 (KM424C256,100 nsec). 


Texas Instruments Digital signal processor designed specifically for parallel processing includes six communi- 

TMS320C40 cation ports, a six-channel DMA coprocessor, and a floating-point processor that performs 

Parallel DSP 275 million operations/sec with 320-Mbyte/sec throughput. Third-party development tools 

are available. Cost: $560. 


Texas Instruments 
SN74ABT series 
ABT transceivers 


Toshiba 
TC55B family 
BiCMOS SRAMs 


Xicor 

XM28C040, 
XM28C010P 
EEPROM modules 


Advanced BiCMOS-technology devices include two standard octal bus transceivers with 
registers (SN74ABT646A, SN74ABT652A) and two functions in the Widebus family — a 
16-bit buffer/driver (SN74ABT16244) and an 18-bit bus transceiver (SN74ABT16500A). 
Packaged in 48- and 56-pin shrink SOPs. Cost (in 1,000s): from $4 to $9.40. 

One-megabit SRAMs, including versions with 12-nsec access time, have a BiCMOS struc¬ 
ture that combines bipolar and CMOS silicon technologies on a single substrate. A new pin 
layout reduces noise generated by ground and voltage-supply pins. Available in DIPs and 
SOJ packages. Cost: $320 (12-nsec version). 

High-density 5 V electrically erasable programmable read-only memory modules in flexible 
configurations. XM28C040 is a fully decoded 32-pin DIP comprising four 1 -Mbit EEPROMs 
on a ceramic substrate. XM28C01 OP comprises four high- speed 256K LCCs mounted on a 
1-in.-square, 66-pin substrate. Both modules feature MultiPlan architecture. Cost (in 100s): 
$2,500 (XM28C040); $1,650 (XM28C010P). 
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T. Nguyen, IBM 

M. Perlin, CMU 

R. Uthurusamy, GM 

K. Valavanis, USWL 
J. Yen, UTAM 

Organizing Chair 

N. Bourbakis, SUNY- 
Binghamton 

Treasurer 

J. Delgado-Frias, SUNY- 
Binghamton 

Registration Chair 

P. Sheu, Rutgers Univ. 
Publicity Chairs 
M. Ibrahim, EDS 

R. Brause, J.W. Goethe Univ. 

L. Marinos, Erasmus Univ. 

S. Y.-Juang, Taiwan National 
Univ. 

J.J. Tsai, Univ. of Illinois 


4th International Conference on 

TOOLS 

WITH 

ARTIFICIAL 

INTELLIGENCE 

November 10-13, 1992 ■ Arlington, Virginia 

Sponsored by IEEE Computer Society 


This conference encompasses the technical aspects of specifying, designing, implementing, and 
evaluating tools with artificial intelligence and tools for artificial intelligence applications. The topics 
of interest include the following aspects: 


• AI Applications 

• Parallel Processing and Hardware Support 

• Artificial Neural Networks 

• Intelligent Robotics 

• Reasoning Under Uncertainty, Fuzzy Logic 


Machine Learning, Theory and Algorithms 

• AI and Software Engineering 

• AI Knowledge Base Architectures 

• AI Algorithms 

• AI Language Tools 

• Expert Systems and Environments 

INFORMATION FOR AUTHORS 

Authors are requested to submit five copies (in English) of their double-spaced typed manuscript 
(maximum of 25 pages) with an abstract to the program chair by April 15, 1992. The conference 
language is English and the final papers are restricted to seven IEEE model pages. A submission letter 
that indicates which of the conference areas is most relevant to your paper and the postal address, 
electronic mail address, telephone number, and fax number (if available) of the contact author must 
accompany the paper. Authors will be notified of acceptance by July 15, 1992 and will be given 
instructions for final preparation of their papers at that time. Outstanding papers will be eligible for 
publication in International Journal on Artificial Intelligence Tools. 

Submit papers by April 15, 1992 to: 

Prof. Harry E. Stephanou 

New York State Center for Advanced Technology in Automation and Robotics 
Rensselaer Polytechnic Institute 
Troy, NY 12180 USA 

518/276-6156; (518)276-6965 (secy); (518)276-4897 (fax) 

TUTORIALS & PANELS 

In addition to papers, proposals for panels and one-day tutorials are solicited in any of the 
conference areas. Such proposals should be submitted to the tutorial-panel chair by April 15, 1992: 
Prof. Susan N. Gottschlich 
Dept, of Electrical Engineering 
Rensselaer Polytechnic Institute 
Troy, NY 12180 USA 

IEEE Computer Society 211 elect^cs^nqineers, wc 

IEEE 

□ Please send me more information about the 4th TAI: 


Company _ 
Address_ 


Country' ■ .' ' j ; - ' . - - _ 

Send to: Nikolaos G. Bourbakis 

Dept, of Electrical Engineering/SUNY at Binghamton 
Binghamton, NY 13902 

(607)777-2165; (607)777-4822 (fax); Email: bourbaki@bingvaxu.cc.binghamton.edu 

















Microsystem Announcements 


Company, Model, Function 


Ariel Based on four TMS320C40 DSP chips, the V-C40 delivers processing power of 1.1 billion 135 

V-C40 operations/sec and data movement at 1.3 Gbytes/sec—a new record for a 6U VMEbus co- 

VMEbus coprocessor processor board. Includes 64 Mbytes of onboard DRAM and up to 5 Mbytes of O-wait-state 

SRAM. Acts as either bus master or slave; supports VMEbus block transfers and DM A 
transfers via VMEbus at 35 Mbytes/sec. Includes onboard bootstrap EPROM. Cost: $9,995. 

Adapter consists of two cards that connect a Sun SBus to a 6U VMEbus. Allows either 136 

system to be a bus master on the other and any Sun Sparcstation to be expanded into a VME¬ 
bus system. Supports two methods of intersystem communication: memory mapping and 
DMA controller. The latter moves large blocks of data at transfer rates up to 20 Mbytes/sec. 

Cost: $2,850. 

AT- and EISA-compatible boards combine a precision frame grabber and a TMS34020 137 

graphics processor to acquire and digitize standard and nonstandard video signals and dis¬ 
play them on a single VGA monitor. Windows graphics can be mixed with images; images can 
be acquired while noninterlaced video is being displayed. Dual buffers allow images to be 
scaled and placed anywhere in the display without corrupting image data. Cost: from $2,995. 

SuperVGA graphics accelerator card, based on Tseng Labs ET4000, features 16 colors in 138 
1,280 x 1,024 resolution and 32,768 colors in 640 x 480 resolution; graphics processor embed¬ 
ded in onboard chip set; and drivers for Windows 3.0, AutoCAD, and other applications for 
IBM PC/XT/AT compatibles. Cost: $335 (512K version); $385 (1-Mbyte version). 

EISA and 386/486-compatible, 32-bit video graphics adapter board produces display reso- 139 

lutions of 1280 x 1024 x 16 colors, noninterlaced. Comes standard with 2 Mbytes of RAM; 
accommodates almost all types of 1280 monitors; based on Tseng Labs ET4000 controller. 

Cost: $895. 

Video capture boards for ISA-bus PCs support VGA, including pass-through of VGA and 140 

extended/superVGA signals. Monochrome models support 256 gray levels and color models 
support 32,768 colors. Features include a choice of512 x 512,640 x 480, or 768 x 512 resolu¬ 
tion; 1K x 24-bit output lookup tables; and four-channel multiplexer. Cost: from $995. 

Based on Intel i860, the *M860 delivers 40 MIPS at 40 MHz. It implements the Multibus II 141 

parallel system bus interface, capable of 40-Mbyte/sec transfer rates. Supports Unix S VR4 
and comes in flexible configurations of 8- or 32-Mbyte DRAM with 33- or 40-MHz CPUs. 
Single-board computer Cost: from $10,995. 

National Instruments AT-DSP2200 is a DSP accelerator board with high-accuracy audio frequency analog I/O 142 

AT boards capabilities. AT-A2150 is an audio frequency analog input plug-in board that digitizes sig- 

Data acquisition nals over bandwidths ranging from DC to 20 kHz. AT-AO-6 and AT- AO-10 are high- 

performance analog output boards. All boards include, free of charge, NI-D AQ DOS and 
NI-D AQ Windows software driver packages for applications development. 

National Instruments Series of boards to enhance Macintosh Quadra computers includes functions for IEEE-488 143 

NB Series instrument control, plug-in data acquisition, and DSP. NB Series takes advantage of the new 

Plug-in boards block-mode DMA capability of the Quadra to pass data directly into memory at high rates. 

For example, the NB-DMA2800 provides DMA service to all of the NB Series boards for 
precise synchronization of multiple boards. Cost: from $245 to $4,995. 

Spectrum Signal Parallel-processing DSP module complies with TIM-40 specification. Features include the 144 

Processing new TMS320C40 processor running at 50 MHz; up to 385Kword, 0-wait-state SRAM; six 

MDC40S 20-Mbyte/sec parallel communication ports; and a 2-Gword global expansion bus. Cost: 

DSP module from $3,500. 


Bit3 Computer 
Model 467 
VME adapter 


Data Translation 
DT3851 series 
Image processors 


Glad Systems 
FlashView 
Graphics accelerator 


Helio Computers 
EISA 1280 
VGA adapter board 


Imaging Automation 
FG-15XX series 
Video digitizers 


Mentec Computer 

Systems 

*M860 


Univision Technologies Half-length mezzanine card provides a video rate path between UT’s Scorpion VGA frame 145 
MZ-UT01 grabber and the Eighteen Eight Laboratories PL2500 floating-point array processors. 

Interface card Transfers multiple 640 x 480 x 8-bit images in real time. Also transfers smaller areas of inter¬ 

est. The PL2500 processors are low-cost, high-speed computational engines for ISA-bus 
computers. The MZ-UT01 mounts directly on it. Cost: $495. 
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CALL FOR PAPERS 


Fifth ISMM International Conference 
on 

PARALLEL AND DISTRIBUTED 
COMPUTING AND SYSTEMS 



ISMM 


October 1-3,1992 
Pittsburgh, Pennsylvania 


SPONSORS: 

The International Society for Mini and Microcomputers 
The Pittsburgh Supercomputing Center 


LOCATION: 

Greentree Marriott, Pittsburgh, PA 


SCOPE: 

* Parallel and distributed supercomputing 

* Optical computing and interconnection systems 


Keynote lectures and special sessions will be devoted to these themes. In addition to the above themes, the 
scope of the conference covers the following areas: 


* Reconfigurable systems 

* Interconnection networks 

* Partitioning and scheduling 

* Non-homogeneous systems 

* Performance measurements 


* Processor arrays 

* Neural networks 

* Parallel algorithms 

* Distributed database 

* Distributed AI systems 


* Distributed Computing 

* Reliability and fault tolerance 

* Parallel languages and compilers 

* Applications of parallel computing 


SUBMISSION OF PAPERS: 


Four copies of a manuscript (maximum 15 double spaced pages) should be submitted before March 25, 
1992 to the program chair. All submitted papers will be reviewed for merit and content, and papers will be 
accepted as regular papers or short papers. The authors of short papers will be given the choice of either 
making a short oral presentation or presenting their work in a poster session. Notification of 
acceptance/rejection will be mailed by June 29, 1992. Camera-ready papers for inclusion in the proceedings 
will be due on July 31,1992. 

INTERNATIONAL PROGRAM COMMITTEE: 


Zary Segall (General chair) 
Department of Computer Science 
Carnegie Mellon University 
Pittsburgh, PA 15213 
(412) 268-3736 


Rami Melhem (Program chair) 
Department of Computer Science 
The University of Pittsburgh 
Pittsburgh, PA 15260 
(412) 624-8426 
Email:melhem@cs.pitt.edu 


Taieb Znati (Local arrangement chair) 
Department of Computer Science 
The University of Pittsburgh 
Pittsburgh, PA 15260 
(412) 624-8417 


S. Akl, Queen's U., Canada 
N. Alexandridis, G. Washington U., USA 

R. Ammar, U. of Connecticut, USA 

S. Bokhary, U. of Eng. and Technology, Pakistan 
E. Deprettere, Delft U., The Netherlands 

J. Fortes, Purdue U„ USA 
B. Furht, Modcomp, USA 

R. Gupta, U. of Pitsburgh, USA 

K. Hwang, U. of Southern California, USA 


O. Ibarra, U.C. Santa Barbara, USA 

H. Jordan, U. of Colorado, USA 
S. Y. Kung, Princeton U., USA 
S. Levitan, U. of Pittsburgh, USA 

I. Mahgoub, Florida Atlantic U., USA 

L. Ni, Michigan State U., USA 

Y. Robert, Lab. Inf. du Parallelisme, France 
R. Roskies, Pitt Supercomputing Center, USA 
H. Sholl, U. of Connecticut, USA 

M. Valero, U. Politecnica de Catalunya, Spain 






CAREER OPPORTUNITIES 


RATES: $15.00 per line (ten lines 
minimum). Average five typeset words 
per line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified 
Advertising, COMPUTER Magazine, 
10662 Los Vaqueros Circle, PO Box 
3014, Los Alamitos, CA 90720-1264; 
(714) 821-8380; fax: (714) 821-4010. 


SYSTEMS SOFTWARE ENGINEER 

Design, develop, test, code, and maintain 
assigned software modules under manage¬ 
ment supervision, providing engineering 
support on assigned system modules. Ana¬ 
lyze computer information systems, pro¬ 
cedures, and problems within the UNIX Sys¬ 
tem, utilizing C programming language. 
Analyze current database operations and 
procedures to determine software require¬ 
ments and evaluate existing system effec¬ 
tiveness. Design and develop network data 
communications systems, utilizing program¬ 
ming languages and software systems such 
as Unix Kernel programming, IBM SNA 
communications, LAN Protocols-NetBios, 
and OSI Communications Protocols. Docu¬ 
ment technical design specifications and pro¬ 
prietary software requirements including 
hierarchical and relational database access¬ 
ing and retrieval. Conduct special studies 
and investigations pertaining to develop¬ 
ment of new information systems to meet 
current and projected needs. Design and 
specify specialized software systems. Inter¬ 
face with appropriate personnel to deter¬ 
mine the specifications of the proposed 
computer program or system. Requires a 
Bachelor's degree in Computer Science and 
two years experience in job offered or two 
years directly related network data commun¬ 
ication systems experience. Or will consider 
a Master's degree in Computer Science in 
lieu of the Bachelor and two years ex¬ 
perience. Must have one year experience in 
Network Communications, “C” language 
and UNIX operating systems. 40 hour work 
week. $39,966.00 per year. Apply at the 
Texas Employment Commission, Dallas. 
Texas, or send resume to the Texas Employ¬ 
ment Commission, TEC Building, Austin, 
Texas 78778. Job Order #6421852. Ad 
Paid by an Equal Employment Opportunity 
Employer. 


UNIVERSITY OF NEW MEXICO 
Chair, 

Department of Computer Science 

The Computer Science Department of the 
University of New Mexico invites applicants 
for the position of department chair. We 
seek an individual with a Ph.D. in computer 
science or related field who has a commit¬ 
ment to both research and teaching excel¬ 
lence. The applicant must have a strong 
desire to work with the faculty toward 
improving the department’s research com¬ 
ponent, a strong publication record in com¬ 
puter science, and strong ties to the com¬ 


puter science research community. Prior 
administrative experience also is desirable. 

The Computer Science Department con¬ 
sists of 15 full time faculty, and confers ap¬ 
proximately 30B.S., 15 M S., and 2 Ph.D’s 
degrees annually. The Bachelor’s program is 
accredited by the Computing Sciences Ac¬ 
creditation Board. Faculty research interests 
include artificial intelligence, automated rea¬ 
soning, complexity and algorithm theory, 
computer security, database systems, 
genetic algorithms and emergent computa¬ 
tion, graphics, image and pattern analysis, 
numerical analysis, numerical software, 
parallel and distributed systems, and pro¬ 
gramming languages. The Department runs 
a network of 5 servers, 35 workstations, and 
10 X terminals, including graphics worksta¬ 
tions from DEC and SGI. 

The University's proximity to Sandia and 
Los Alamos National Laboratories and to the 
Santa Fe Institute affords unique opportuni¬ 
ties for collaborative research opportunities. 
Additionally, Albuquerque offers an excellent 
quality of life, with a mild climate year round 
and easy access to superb recreational ac¬ 
tivities, including skiing, hiking, and camping. 
Please send vitae and list of references to: 
Professor Paul Helman 
Chair, Search Committee 
Computer Science Department 
University of New Mexico 
Albuquerque, NM 87131 
Email: helman@unmvax.cs.unm.edu 
Applications will be accepted until Febru¬ 
ary 1, 1992. Later applications if the position 
has not been filled. The University of New 
Mexico is an Equal Opportunity/Affirmative 
Action Employer. 


UNIVERSITY OF MASSACHUSETTS 
AMHERST 

Faculty and Research Scientist 
Positions 

The Department of Computer and Infor¬ 
mation Science invites applications for 
tenure-track and research faculty positions at 
all levels in all areas of computer science. 
Applicants should have a Ph D. in computer 
science or related area and show evidence of 
exceptional research promise. Senior level 
candidates should have a record of distin¬ 
guished research. Salary is commensurate 
with education and experience. Our Depart¬ 
ment has grown substantially over the past 
five years and currently has 38 full-time 
tenure-track and research faculty, approx¬ 
imately 10 postdoctoral research scientists, 
and 160 graduate students. Continued 
growth is expected over the next five years. 
We have ongoing research projects in robo¬ 
tics. vision, natural language processing, ex¬ 
pert systems, distributed problem solving, 
person-machine interfaces, distributed pro¬ 
cessing. database systems, information re¬ 
trieval, operating systems, object-oriented 
systems, persistent object management, real¬ 
time systems, software development and 
analysis, programming languages, computer 
networks, theory of computation, office 
automation, parallel computation, computer 


architecture, and medical informatics (with 
UMass Medical School). 

The Department has recently established a 
national center (CRICCS) for research on 
real-time, intelligent complex computing 
systems. We also have a major project (Pro¬ 
ject Pilgrim) with Digital on distributed, 
heterogeneous networks, an NSF/CII award 
in the area of computer vision, distributed 
AI and real-time systems, and five-year 
DoD/URI Center of Excellence in Artificial In¬ 
telligence. To support our research, we have 
an extensive research computing facility, in¬ 
cluding over 200 Sun. VaxStation, DecSta- 
tion and TI Explorer workstations, numerous 
servers, two Sequent Balance Microproces¬ 
sors. a 4096-node Connection Machine, a 
variety of graphic devices, both Salisbury and 
Utah/MIT robotic hands, a Denning mobile 
robot and a real-time testbed. Send vita, along 
with the names of four references to: Pro¬ 
fessor Allen Hanson. COINS Department. 
Lederle Graduate Research Center, Univer¬ 
sity of Massachusetts, Amherst. MA 01003. 
by April 1. 1992. 

An Affirmative Action/Equal Opportunity 
Employer. 


D.E. SHAW & CO. 

Algorithmic Trading 

D.E. Shaw & Co. is a small (several dozen 
employees), highly capitalized (over $300 
million in partners' equity), extremely suc¬ 
cessful Wall Street firm specializing in quan¬ 
titative finance and computational trading. 
Computer scientists and system designers 
form the professional core of the firm, and 
not merely its support staff, and participate in 
its profits. Our technical staff includes both 
Ph.D.-level researchers recruited from Stan¬ 
ford. MIT. and other leading computer sci¬ 
ence departments and extraordinarily talented 
B.S.-and M.S.-level system designers and 
"superhackers". It is our practice to compen¬ 
sate unusually gifted individuals at a level ex¬ 
ceeding that of the market. Applicants should 
send resumes to Jennifer Strulson, D.E. 
Shaw & Co.. 39th Floor. Tower 45, 120 W. 
45th St., New York. NY 10036. 


FACULTY FOR EUROPE AND ASIA 

Planning a sabbatical or leave of absence? 
The University of Maryland University 
College seeks excellent lecturers for under¬ 
graduate computer science, computer appli¬ 
cations, and information systems manage¬ 
ment courses on U.S. military bases in 
Europe and in Asia and the Pacific. Renew¬ 
able annual appointments begin August 
1992. Minimum requirements include a 
master's degree in computer science or a 
related field, recent college teaching ex¬ 
perience, and U.S. citizenship. Benefits in¬ 
clude transportation and military base 
privileges. Frequent travel and the cost of 
schooling make these positions difficult for 
those with children. Send resume to: Dr. 
Ralph E. Millis. Overseas Programs. The 
University of Maryland University College, 
College Park. MD 20742-1642. AA/EEO. 
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PROGRAMMER / ANALYST 

Provide analytical, design, and program¬ 
ming support to Financial Accounting Sys¬ 
tem, Cost Accounting System and Material 
Control System. Perform EDP auditing and 
security control on the Accounting System. 
Detail the logical and mathematical opera¬ 
tions performance by various mainframe 
computer equipment, and overall computer 
programs together with the operations per¬ 
formance by personnel within such systems. 
Analyze business procedures and problems 
of in-house user, refining data and convert¬ 
ing it to programmable form. Liaise with per¬ 
sonnel of Financial and Manufacturing De¬ 
partments to determine exact output needs 
which include type of breakout, degree of 
summarization and format for management 
reports. Study existing company hardware 
base information system to evaluate their ef¬ 
fectiveness and to develop new systems to 
improve production and workflow. Requires 
a Bachelor's degree in Computer Informa¬ 
tion Systems/Management Information 
Systems, or its equivalent and two years ex¬ 
perience in job offered or two years directly 
related experience involving operating sys¬ 
tems, JCL, Online database control system, 
teleprocessing monitoring, CODASYL data¬ 
base, Virtual Storage file access system, and 
structured COBOL and report generator. 40 
hour work week. $28,000.00 per year. Ap¬ 
ply at the Texas Employment Commission, 
Dallas, Texas, or send resume to the Texas 
Employment Commission, TEC Building, 
Austin, Texas 78778. Job Order *6344578. 
Ad paid by an Equal Opportunity Employer. 


PORTLAND STATE UNIVERSITY 
Computer Science Department 
Tektronix Professorship 

The Tektronix Foundation has awarded 
Portland State University a $360,000 grant 
to upgrade its curriculum, establishing a new 
tenure-track faculty position, with significant 
ancillary support. This new position can be at 
the junior or senior level. 

We invite applications and/or nomina¬ 
tions for this position. Applicants must have 
an earned doctorate. Responsibilities include 
undergraduate and graduate teaching, de¬ 
velopment of sponsored research, and in¬ 
teraction with local industry. The position is 
available beginning Fall 1992. 

Preference will be given to applicants in 
areas of interest to local business and in¬ 
dustry. The department is particularly in¬ 
terested in candidates in Software Engineer¬ 
ing, but is also interested in applicants in the 
areas of Operating Systems, Database Sys¬ 
tems, and Human-Computer Interaction. 

Portland State University, one of the three 
major universities in the Oregon State 
System of Higher Education, is located in the 
heart of Portland, Oregon. The campus is 
downtown, near to parks, shopping, and the 
theater district. Portland is a beautiful city 
which offers a diversity of recreation within 
easy driving distance—unequaled fishing 
(salmon and steelhead within a mile of cam¬ 
pus). skiing and mountain climbing, the 
scenic Oregon coast and unmatched state 
campgrounds, to name a few. 

PSU's Computer Science Department is 
located in the Portland Center for Advanced 
Technology, which houses both the Elec¬ 


trical Engineering and Computer Science 
departments, plus CAD/CAM, VLSI de¬ 
sign, computer vision and optical com¬ 
munications laboratories. The CS depart¬ 
ment operates a network of UNIX, Al, 
parallel processing and graphics systems and 
workstations. 

Portland has a rapidly growing computer 
and electronics industry including Tektronix, 
Intel, Servio Logic, Sequent Computer Sys¬ 
tems, Mentor Graphics, and Oregon Soft¬ 
ware, permitting close industry-university in¬ 
teraction. The excellent research facilities 
and faculty of the Oregon Graduate Institute 
are only a few miles away. 

Send applications, including a resume 
and the addresses of three references, to: 
Leonard Shapiro 
Department of Computer Science 
Portland State University 
P.O. Box 751 
Portland, OR 97207 
Telephone: (503) 725-4036 
len@cs.pdx.edu 

Non-U.S. Residents must state their visa 
status. Portland State University is an equal 
opportunity/affirmative action employer. 
Minorities, women, and members of other 
protected groups are encouraged to apply. 
Deadline February 15, 1992 or until the 
position is filled. 

UNIVERSITY OF ALBERTA 
Department of Computing Science 

Applications are invited for a tenure-track 
position at the Assistant Professor level in the 
areas of computer graphics and/or human 
interfaces. Excellent senior applicants will 
also be considered in these areas. Responsi¬ 
bilities include research as well as teaching at 
both the graduate and undergraduate levels. 

This young and energetic department has 
recently undergone significant expansion 
and consists of 35 academic and 29 support 
staff. Current hardware support for research 
includes a local area network consisting of a 
MIPS M/120 and Silicon Graphics 4D/340S 
computer connecting over 75 Sun Worksta¬ 
tions and a large number of terminals. Cur¬ 
rent computer graphics facilities include two 
Silicon Graphics workstations, a Data Glove, 
a head-mounted display, a single frame 
video recorder and two colour sun worksta¬ 
tions. The department also operates a Myrias 
SPS-2 massively-parallel computer as a re¬ 
search tool. Well-supported laboratories also 
exist for AI. database, distributed systems, 
image processing, programming languages 
and robotics research. 

The current salary range minimum is 
$C38,955 with the appointment level being 
commensurate with qualifications and ex¬ 
perience. Send curriculum vitae, the names 
of three references and up to three reprints 
or copies of important publications. New 
Ph.D.'s should include a copy of their 
transcript. 

Apply to: 

Dr. Paul G. Sorenson 
Department of Computing Science 
University of Alberta 
Edmonton, Alberta, Canada 
T6G 2HI 

Applications will be accepted until Febru¬ 
ary 29. 1992. 

In accordance with Canadian Immigration 
requirements, priority will be given to Cana¬ 


dian citizens and permanent residents of 
Canada. 

The University of Alberta is committed to 
the principle of equity in employment. The 
University encourages applications from 
aboriginal persons, disabled persons, mem¬ 
bers of visible minorities, and women. 


COMPUTER ENGINEERING 
PENN STATE 

Applications are invited for tenure-track 
faculty positions at all levels. Candidates 
from all areas of computer engineering will 
be considered; however priority will be given 
to those candidates in Software Engineering. 
Candidates should have a Ph.D. in Compu¬ 
ter Engineering or a related discipline, ability 
to establish a strong research program, and a 
desire to teach at both the undergraduate 
and graduate levels. The Department of 
Electrical and Computer Engineering at 
Penn State currently has over 50 faculty, 
800 junior and senior level students, and 
280 graduate students. The Computer Engi¬ 
neering Program is within the Department of 
Electrical and Computer Engineering. About 
12 faculty members, 140 junior and senior 
level students, and 65 graduate students 
belong to this Program, which awards B.S., 
M.S. and Ph.D. degrees in Computer Engi¬ 
neering. Research activities currently exist.in 
Parallel and Distributed Processing. Inter¬ 
connection Networks, Fault Tolerant Com¬ 
puting, Image Processing and Computer 
Vision, Database Systems, VLSI, and Com¬ 
puter Communications. Please send resume 
and cover letter, with names, addresses and 
phone numbers of at least three references 
to: Personnel Committee, Department of 
Electrical and Computer Engineering, 121 
EE East, The Pennsylvania State University, 
University Park, PA 16802. Applications 
received by December 31, 1991 will be as¬ 
sured of consideration; however applications 
will be considered until positions are filled. 
An equal opportunity/affirmative action em¬ 
ployer-women and minorities are encour¬ 
aged to apply. 


SOFTWARE ENGINEER 

Design, code, integrate, and test software 
for several modules of a support basis for 
other systems such as User Interface and 
Prototyping. Perform work from high-level 
architecture, design, and interface specifica¬ 
tions. Utilize Sun workstations, UNIX 
operating system, C and C+ + languages, 
object-oriented and relational databases. 
Build interfaces between relational and 
object-oriented databases. Master's degree 
in Computer Science or Engineering re¬ 
quired. One year experience in job offered 
or software development required. Experi¬ 
ence must include C and C+ + program¬ 
ming languages and object-oriented exten¬ 
sions to those languages; experience with 
Sun workstations and Unix operating sys¬ 
tems; experience with relational databases. 
Hours are 8:30 a.m. to 5:30 p.m., 40 hours 
weekly, at an annual salary of $36,147.50. 
Apply at the Texas Employment Commis¬ 
sion, Austin, Texas, or send resume to the 
Texas Employment Commission, TEC Build¬ 
ing, Austin. Texas 78778, J.O. *6599115. 
Ad Paid by an Equal Opportunity Employer. 
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GEORGE MASON UNIVERSITY 
Faculty Positions in Computer Science 

The Department of Computer Science at 
George Mason University is seeking appli¬ 
cants for tenure-track and tenured faculty 
positions at the ranks of assistant, associate, 
and full professor. We are interested in per¬ 
sons who are dedicated to teaching and pro¬ 
fessional service and whose research special¬ 
ties include algorithms and data structures, 
programming languages, architecture, nu¬ 
merical and symbolic computation, operat¬ 
ing systems, software engineering, artificial 
intelligence, human-computer communica¬ 
tions. and computational science. We are 
primarily interested in full-time faculty, but 
may consider visiting faculty as well. The 
nominal starting date of appointments is 
September 1, 1992. 

George Mason University is located in 
Fairfax County Virginia, seventeen miles 
from Washington. D.C. The Department of 
Computer Science is in the School of Infor¬ 
mation Technology and Engineering, which 
has made a commitment to engineering edu¬ 
cation in a world shaped by information 
technologies. There are numerous oppor¬ 
tunities for government and industrial in¬ 
teraction in this region. 

For full consideration please send a letter 
of application, a detailed resume, samples of 
at most two recent publications, and the 
names of four references, to Professor Peter 
J. Denning. Chair, Recruitment Committee. 
Department of Computer Science. George 
Mason University. Fairfax. VA 22030-4444. 
or call at (703) 993-1530 (e-mail: pjd@cs. 
gmu.edu). The applications letter should 
state your professional goals and aspirations. 
Final date for applications is February 1. 
1992. AA/EOE 


UNIVERSITY OF SOUTH FLORIDA 
Center for Microelectronics Research 
Faculty Position 

The Center for Microelectronics Research 
at the University of South Florida invites ap¬ 
plications and nominations for a tenure-track 
faculty position at the Associate or possibly 
full Professor level to begin employment 
August 1992. Applicants or nominees should 
have achieved national and international 
prominence in microelectronics design or 
design tools and must have an earned doc¬ 
torate and a documented record of out¬ 
standing industrial experience and/or uni¬ 
versity research and teaching experience. 
The successful applicant will be expected to 
develop a strong funded research program 
in his/her area of expertise and to also teach 
one graduate or undergraduate course per 
semester. 

A joint faculty appointment in both CMR 
and the Department of Computer Science 
and Engineering is anticipated. CMR is a 
center of excellence in microelectronics 
which was established by a special legislative 
appropriation of the State of Florida to USF. 
CMR has benefitted from strong research 
funding which totals in excess of $12 million 
over the past three years and has outstand¬ 
ing VLSI/ULSI and wafer scale design, test 
and rapid prototyping laboratories with SUN 


SPARC workstations running Cadence 
VLSI Design and Intermetrics VHDL tools 
plus an HP82000 high speed digital test 
system. CMR currently has seven tenured or 
tenure-track faculty who hold joint appoint¬ 
ments in CMR and either the Computer Sci¬ 
ence and Engineering, the Electrical Engi¬ 
neering or the Physics Departments, plus 
eight full-time senior research staff. 

USF is an Affirmative Action/Equal Op¬ 
portunity Employer. Nominations or appli¬ 
cations should be directed to Dr. Earl Claire. 
Chairman, Search Committee, CMR/Col- 
lege of Engineering, University of South 
Florida. 4202 E. Fowler Avenue. Tampa, 
FL 33620. 


SYSTEMS DESIGN ENGINEER 

Systems Design Engineer required. Re¬ 
sponsible for development, programming, 
monitoring and analysis of computer ar¬ 
chitecture and operating systems including 
support of computer simulation models and 
optimization algorithm, database design and 
optimization. Database Management Sys¬ 
tems. Object Oriented Programming, Knowl¬ 
edge Engineering and Software Engineer¬ 
ing. Will utilize C. C++, RDBMS, Lisp. 
SQL and UNIX. Applicants required to have 
a Masters Degree or its equivalent in Com¬ 
puter Science with at least one year ex¬ 
perience with UNIX/C, C++. SQL. Lisp, 
RDBMS, and Object Oriented Program¬ 
ming. Experience must include prior work 
with design and analysis of optimization 
algorithms system simulations and the design 
of compiling and programming systems. 
Graduate project work in these areas. An an¬ 
nual salary of $42,000 will be paid for a 
4Q-hour work week. Must have proof of legal 
authority to work in the U.S. Interested 
applicants apply at the Texas Employment 
Commission, Ft. Worth. TX, or send resume 
to the Texas Employment Commission. 
Austin, TX 78778-0001. J.O. Number 
6421878. This advertisement was paid by an 
Equal Opportunity Employment employer. 


TEXAS A&M UNIVERSITY 

Department of Computer Science 

Applications are invited for faculty posi¬ 
tions at the Assistant, Associate, or Full Pro¬ 
fessor level. Particular areas of interest in¬ 
clude databases, graphics, fault tolerant 
computing and VLSI/testing but outstand¬ 
ing candidates from all areas will be 
considered. 

Texas A&M provides superior instruc¬ 
tional and research facilities for its Computer 
Science faculty and is committed to a major 
expansion of its research and instructional 
program in Computer Science. The Depart¬ 
ment is a branch of Texas A&M’s College of 
Engineering which is one of the nation’s 
largest. Currently the Department has a 
roster of 28 full-time graduate faculty 
members with a number of new positions 
being added this year. In September of 1988 
the Department initiated a program in Com¬ 
puter Science and Engineering to comple¬ 
ment its degree offerings in Computer 


Science. In January of 1990 the Department 
moved into a new building with 50,000 
square feet of space. The Department's 
equipment includes a 64 node NCUBE, a 
2000 node MASPAR, Sequent Balance, 
numerous SPARC4, Silicon Graphics, Sym¬ 
bolics, NeXT, and real time system work sta¬ 
tions as well as access to the University’s 
Cray YMP2/116, IBM 3090/200E, Amdahl 
5860, and more. The current annual exter¬ 
nal research funding in the Department is ap¬ 
proximately $2.5 million. 

The program seeks excellence in research. 
Applicants at the Assistant professor level 
should show substantial promise for research 
and teaching. Applicants at the higher levels 
should show a strong record of research 
achievement. Ability in teaching graduates 
and undergraduates is essential. Applicants 
should have a doctoral degree or equivalent. 
Applicants should submit a resume and 
three references to Donald K. Friesen, 
Chairman, Faculty Search Committee, 
Computer Science Department, Texas 
A&M University, College Station, TX 
77843-3112. 

Texas A&M University is an equal oppor¬ 
tunity/affirmative action employer. 


DELTA PERSONNEL SERVICES 

Programmers, MIS Managers, Computer 
Operators—contract and permanent posi¬ 
tions. Send resume indicating hardware and 
software knowledge, geographic preference, 
shift preference, availability and salary re¬ 
quirements. Referral fees and commissions 
granted for openings (job orders) and can¬ 
didates. Send resume to: 

Norma Brody 
DELTA Personnel Services 
2045 Royal Ave., #221 
Simi Valley, CA 93065 


DATABASE DESIGN ENGINEER 

Database Design Engineer required. 
Responsible for development, program¬ 
ming, monitoring and analysis of database 
architecture and database systems including 
support of computer simulation models and 
optimization algorithms. Expert Systems 
(Artificial Intelligence). Network analysis. 
Database Management Systems and Soft¬ 
ware Engineering. Will utilize C. C + +. 
Pascal. Lisp. VMS. UNIX and X-Windows. 
Applicants required to have a Masters 
Degree or its equivalent in Computer 
Science with at least one year experience 
with UNIX/C. VMS. AI. Pascal. Lisp, and 
X-Windows. Experience must include prior 
work with analysis of optimization algorithms 
and simulation models. Graduate project 
research work in this area will be acceptable. 
An annual salary of $42,000 will be paid for 
a 40-hour work week. Must have proof of 
legal authority to work in the U.S. Interested 
applicants apply at the Texas Employment 
Commission. Ft. Worth. TX. or send resume 
to the Texas Employment Commission. 
Austin. TX 78778-0001. J.O. Number 
6421873. This advertisement was paid by an 
Equal Opportunity Employment employer. 
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STATE UNIVERSITY OF NEW YORK 
AT BINGHAMTON 
Department of Computer Science 
The Watson School of Engineering 

The State University of New York at Bing¬ 
hamton invites applications for tenure-track 
positions in the Department of Computer 
Science beginning August 1992. Salary is 
competitive. Preferred areas of specialization 
include distributed/parallel systems, distri¬ 
buted databases, programming languages/ 
compilers, and networking/parallel architec¬ 
tures, but applicants in all areas of Computer 
Science will be considered. Applicants must 
have a Ph.D. in Computer Science or a 
related area, and possess a strong commit¬ 
ment to research and teaching. 

The Department has established Ph.D. 
and M.S. programs, and an accredited 
B.S. program. High technology computer- 
oriented companies in the local area such as 
IBM, G.E., Link Flight Simulation, and Uni¬ 
versal Instruments provide opportunities for 
industrial collaboration. 

Send nominations or applications includ¬ 
ing a resume and the name of three refer¬ 
ences to Professor Sudhir Aggarwal, Chair¬ 
man, Department of Computer Science, 
The Watson School, State University of New 
York at Binghamton, P.O. Box 6000, Bing¬ 
hamton, New York 13902-6000. Applica¬ 
tions received by February 15, 1992 will 
receive first consideration. 

The State University of New York at Bing¬ 
hamton is strongly committed to affirmative 
action. We offer access to services and re¬ 
cruit students and employees without regard 
to race, color, sex, religion, age, disability, 
marital status, sexual orientation or national 


DUKE UNIVERSITY 
Department of Computer Science 

Applications are invited for the position of 
Chairman, Department of Computer Sci¬ 
ence at the rank of Full Professor with tenure 
beginning September 1992. Candidates 
should have a strong research background 
and teaching experience. 

The position of Chairman allows the op¬ 
portunity to continue an active research pro¬ 
gram while guiding the development of the 
Department. The Department presently has 
approximately twenty faculty, fifty graduate 
students, a modern workstation environ¬ 
ment and an excellent support staff. Twenty- 
six Ph.D. s have been awarded in the past 
five years. 

The Department has major research ef¬ 
forts in: 

• artificial intelligence, particularly in the areas 
of logic programming, natural language 
interface, and search methodologies; 

• computer systems with emphasis on sys¬ 
tems performance, communications, and 
computer architectures: 

• scientific computing with emphasis on 
numerical linear algebra, the solution of 
PDEs, and VLSI simulation: 

• theory and algorithms with emphasis on 
parallel and randomized algorithms; and 

• VLSI design, particularly computer-aided 
design and special purpose architectures. 
Duke University is a highly selective, pri¬ 
vate, research-oriented University located in 
an active research, metropolitan area, which 


includes Research Triangle Park and the Tri¬ 
angle Universities—the University of North 
Carolina at Chapel Hill, North Carolina State 
University and Duke University. 

Applicants should include a curriculum 
vitae, a list of publications, a few most impor¬ 
tant publications and a list of references. 
These should be sent by March 1, 1992 to: 
Search Committee Chairman 
Department of Computer Science 
Room 205 North Building 
Duke University 

Durham, North Carolina 27706 
Duke University is an equal opportunity, 
affirmative action employer. 


UNIVERSITY OF ILLINOIS 
Department of Electrical and 
Computer Engineering 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
several tenure-track and tenured faculty 
positions. Applicants must have an earned 
Ph.D.s, outstanding academic credentials, 
and an ability to teach effectively at both the 
graduate and undergraduate levels. Selected 
candidates will be expected to initiate and 
carry out independent research and to per¬ 
form academic duties associated with our 
B.S., M.S., and Ph.D. programs. Since the 
department is very large, each year several 
vacancies are filled. A continuing search is 
conducted throughout the year to fill open 
positions. All candidates judged as qualified 
for a position will be interviewed. Salary 
open, based on qualifications. Starting date 
is negotiable. The department has one of the 
largest programs in the United States grant¬ 
ing approximately 400 B.S., 100 M.S., and 
65 Ph.D. degrees annually. The department 
is recruiting faculty in all areas of computer 
engineering. Current research interests of 
our computer engineering faculty include 
computer architecture, design complexity 
and theory of computation, high perfor¬ 
mance and reliable computing, knowledge 
engineering, parallel and distributed process¬ 
ing, performance evaluation, robotics and 
computer vision, and VLSI design. 

Send resume, with references and a list of 
publications to: T.N. Trick, Faculty Search 
Committee. University of Illinois, Depart¬ 
ment of Electrical and Computer Engineer¬ 
ing, 1406 West Green Street, Urbana, IL 
61801. Telephone: (217) 333-2301. 

The University of Illinois is an equal op¬ 
portunity /affirmative action employer. 


SYSTEMS ENGINEER 

Systems Engineer (PC & PCB Evaluation), 
40 hrs/wk, 9-6, $36,000/yr. Develop ex¬ 
pert systems for PCB evaluation and trouble¬ 
shooting. PC Board design, review, and 
evaluation, including: multi-layer PCB, 
multi-warePCB, CAM, N/C drilling control, 
and failure analysis. Personal computer and 
network evaluation/modification. Minimum 
requirements: MS or completion all required 
courses for MS in Computer Science, 1 year 
in PC board evaluation/failure analysis. Ap¬ 
ply at the Texas Employment Commission, 
Dallas, Texas, or send resume to the Texas 
Employment Commission, TEC Building, 
Austin, Texas 78778, J.O. #6521507. Ad 
Paid by an Equal Opportunity Employer. 


UNIVERSITY OF ALABAMA 
AT BIRMINGHAM (UAB) 

Nominations and applications are invited 
for a tenure-track position available Fall 
1992. Rank is dependent on qualifications. 
Applicants should have an interest in gradu¬ 
ate and undergraduate teaching and demon¬ 
strated excellence in research. Preference 
will be given to applicants whose research 
record and interests will contribute to 
established strength in parallel/distributed 
computing and graphics/image processing. 

Departmental equipment includes a variety 
of Sun workstations, a 30processor Sequent 
Balance 21000. and access to the Alabama 
Supercomputer Authority Cray XMP/24 
and 128 processor NCUBE. The Depart¬ 
ment is a university affiliate of the Advanced 
Computer Facility at Argonne National 
Laboratory, providing access to a variety of 
parallel machine architectures. Opportuni¬ 
ties are available for multidisciplinary col¬ 
laboration with biomedical researchers in the 
UAB Medical Center. Birmingham is a major 
metropolitan area with a population of near¬ 
ly 900,000 and is a southeastern center of 
finance, telecommunications and medicine. 
UAB is a comprehensive university and 
ranks among the top 20 public universities in 
the U.S. in terms of federally supported 
research and development. Student enroll¬ 
ment is over 16.000. Applicants should hold 
the Ph.D. in computer science or closely 
related field. Screening of applicants will 
begin on February 15. 1992 and will con¬ 
tinue until a successful candidate is found. 
Applications should be addressed to: Dr. 
Warren T. Jones. Department of Computer 
& Information Sciences. UAB Station. Birm¬ 
ingham, AL 35294-1170 (Internet: jones@ 
cis.uab.edu). UAB is an Affirmative Ac¬ 
tion/Equal Opportunity Employer. 


UNIVERSITY OF HARTFORD 
Mathematics and Computer Science 
Department 

West Hartford, CT 06117 

Applications are invited for a full time 
tenure track position beginning September 
1992 at the rank of Assistant Professor of 
Computer Science. Candidates must have a 
Ph.D. in Computer Science in hand or near 
completion, or a Ph.D. in Mathematics with 
an M.S. in,Computer Science and a clear 
commitment to Computer Science. Oppor¬ 
tunity exists^ teach in a naiionally recog¬ 
nized inter-disciplinary general education 
curriculum. Review of applications will begin 
in January and continue until a decision is 
reached. Application package must include 
a resume, three letters of recommendation 
(at least one of which specifically addresses 
teaching). and a teaching statement that ex¬ 
plains your interest and commitment to the 
teaching of undergraduates in Computer 
Science. Send package to Dr. Joel Kagan. 
Chairman. Math/C.S. Dept.. University of 
Hartford. W. Hartford. CT 06117. The Uni¬ 
versity of Hartford is an Equal Opportunity 
Affirmative Action employer and specifically 
invites and encourages applications from 
women, minorities and members of under¬ 
represented groups. 


January 1992 
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WASHINGTON STATE UNIVERSITY 

Computer Science Faculty Positions 

The Departments of Computer Science 
and Electrical Engineering have recently 
merged into a school. We seek to strengthen 
our capabilities in selected areas of computer 
science. Applications are invited for full-time 
tenure-track positions at all professional 
ranks. Responsibilities include undergradu¬ 
ate and graduate teaching and the initiation, 
conduct and supervision of research. Mini¬ 
mum qualifications include a Ph.D. in com¬ 
puter science, or closely allied field, and a 
demonstrated potential for research. Candi¬ 
dates for the higher ranks must have proven 
records of accomplishments as evidenced by 
publications and sponsored research. We 
seek candidates with major interests in 
parallel and distributed computing, or in soft¬ 
ware engineering. Screening will begin Jan¬ 
uary 2, 1992, and continue until all openings 
are filled. Positions start on August 16, 
1992. 

Washington State University has offered 
the Ph.D. degree in Computer Science since 
1970, and also offers the M.S. and B.S. 
degrees. Teaching duties are kept at modest 
levels through a selective certification pro¬ 
cess for undergraduate majors. There are 
approximately 60 computer science 
graduate students involved in a wide variety 
of research topics. Computing facilities in the 
School of Electrical Engineering and Com¬ 
puter Science include a variety of minicom¬ 
puters and networked Unix workstations 
with internet access. 

Washington State University, with about 
16,000 students, is located in Pullman—a 
quiet university town in the southeast corner 
of the state. The climate is moderate with an 
average annual precipitation of about 20 
inches. Nearby are some of the nation’s most 
pristine and uncrowded places for outdoor 
recreation. The Pullman public school sys¬ 
tem is widely acknowledged to be one of the 
very finest in the Northwest. 

To apply, send a resume and the names 
and addresses of at least three references to: 
Dr. Yacov A. Shamash, Director, School of 
Electrical Engineering, and Computer Sci¬ 
ence, Washington State University, Pull¬ 
man, WA 99164-2752. 

WSU is an EO/AA educator and em¬ 
ployer. Protected group members are en¬ 
couraged to apply. 


UNIVERSITY OF MIAMI 

The Department of Math and Computer 
Science will have a tenure-track position in 
computer science starting August or, possi¬ 
bly, January of 1992. Salaries are open, 
commensurate with qualifications. Candi¬ 
dates must have a Ph.D. or equivalent 
degree and an excellent research potential 
with a strong commitment to teaching and 
research. Applicants should send a curri¬ 
culum vita and three references to: 

A.C. Zame, 

Chairman, Department of Mathematics 
and Computer Science 
University of Miami 
P.O. Box 249085 
Coral Gables, Florida 33124 
The University of Miami is an Equal Op¬ 
portunity/Affirmative Action Employer. 


SOFTWARE ENGINEER 

Design, implement and test real time soft¬ 
ware using high level and low level program¬ 
ming languages for trunk signalling, using 
complex signalling systems and traditional 
signalling in Sun Workstation and IBM main¬ 
frame environment. Design signalling data 
link, signalling terminals and signalling net¬ 
work. Prepare function test specifications to 
ensure quality code and accuracy of test. 
Develop communicating interface between 
ISDN user parts which utilizes signalling 
system number 7 protocols for setting up 
speech path in a trunk call. Localize and cor¬ 
rect faults in software. Conduct detailed 
analysis of facts to resolve problems. Report 
findings to management. Assist Jr. Engi¬ 
neers with design and test work to ensure 
correct work methods and training. Requires 
a Bachelor's degree in Computer Science 
and one year experience in job offered or 
one year directly related software design and 
testing of digital telephone switching sys¬ 
tems. Requires at least one year experience 
in telephony and real-time systems, network 
systems and PLEX programming language 
or its equivalent. 40 hour work week. 
$35,700.00 per year. Apply at the Texas 
Employment Commission, Dallas, Texas, or 
send resume to the Texas Employment Com¬ 
mission, TEC Building, Austin, Texas 78778. 
Job Order #6449008. Ad Paid By An Equal 
Employment Opportunity Employer. 


SOUTHERN METHODIST UNIVERSITY 
Computer Science and Engineering 

The Department of Computer Science 
and Engineering (CSE) invites applications 
for a senior faculty position in Computer 
Engineering at the Associate or Full Pro¬ 
fessor level. Applicants must have a Ph.D. in 
Computer Engineering, Computer Science, 
or a related discipline. Candidates should 
have an outstanding funding and research 
record in the area of Computer Engineering 
with a strong commitment to teaching. It is 
anticipated that the position will be filled by 
August, 1992. 

SMU is a private university with approx¬ 
imately 8,000 students. The Department of 
Computer Science and Engineering is in the 
School of Engineering and Applied Science, 
where a close working relationship exists 
with the Department of Electrical Engineer¬ 
ing and Mechanical Engineering. The CSE 
Department presents a balanced program of 
research and education at all levels and has 
been offering Ph.D. degrees since 1970. 
The Department has extensive contacts with 
computer-related and engineering-oriented 
industrial firms that distinguish Dallas as one 
of the top centers for high technology. 

Applicants should send a complete 
resume, including the names of at least three 
references to: 

Professor Margaret H. Eich 
Chair, Faculty Search Committee 
Department of Computer Science 
and Engineering 
Southern Methodist University 
Dallas, Texas 75275-0122 
SMU is an equal opportunity/affirmative 
action, Title IX employer. Applications from 
women and minorities are particularly en¬ 
couraged. Applications will be accepted until 
February 1. 1992. 


DARTMOUTH COLLEGE 

The Department of Mathematics and 
Computer Science at Dartmouth College 
has openings for two tenure-track Assistant 
Professor positions in computer science. Ap¬ 
pointments at higher rank may be possible. 
Candidates must excel in both teaching and 
research. A Ph.D. in computer science is re¬ 
quired. Applications from any field of com¬ 
puter science are encouraged. 

Faculty in computer science conduct re¬ 
search and teach at the graduate level under 
the auspices of the Ph.D. Program in Com¬ 
puter Science, and as members of the 
Department of Mathematics and Computer 
Science they teach undergraduates majoring 
in computer science. The Department of 
Mathematics and Computer Science cur¬ 
rently includes eleven computer science 
faculty, and there are two additional com¬ 
puter science faculty in the Thayer School of 
Engineering who are members of the Ph.D. 
Program in Computer Science. Research in¬ 
terests of the faculty include algorithm 
analysis and design, computer languages 
and systems, theory, computational geome¬ 
try, design automation, VLSI, databases, 
parallel and distributed computation, com¬ 
puter vision, system security, logic program¬ 
ming, and signal processing. 

Interested persons should submit a cur¬ 
riculum vitae, a statement of research plans 
and interests, and at least three, preferably 
four, letters of recommendation, at least one 
of which should comment on your teaching. 
Review of applications will begin immediate¬ 
ly and will continue until the search is com¬ 
plete. Please address application material 
and general inquiries to Phyllis A. Bellmore, 
Mathematics and Computer Science De¬ 
partment, Dartmouth College, 6188 Brad¬ 
ley Hall, Hanover, New Hampshire 03755- 
3551. Specific questions on the selection 
process can be referred to Professor Donald 
Kreider, Recruiting Chair. 

Dartmouth College is an equal Oppor¬ 
tunity/Affirmative Action employer and en¬ 
courages applications from women and 
members of minority groups. 


LOSS CONTROL SYSTEMS 
ENGINEER 

Review field inspection procedures for 
commercial entities risk management assess¬ 
ment. Design LAN system (s) for automation 
of field inspection reporting to streamline 
reporting and reduce inconsistencies in re¬ 
porting. Design software and hardware. 
Establish pilot project to test system in south 
Texas and monitor results. Develop and im¬ 
plement system training programs for field 
reps and others. Travel extensively (700 + 
miles weekly) in south Texas. 40 hour week. 
$21.00 per hour plus travel differential. Re¬ 
quires Masters in CIS or MIS, 1 year in job 
offered or 1 year in position involving cost 
management or consulting. Must have 3 or 
more courses in finance or cost accounting. 
Must be certified or eligible for Texas Board 
of Insurance Field Safety Representative. To 
apply submit resume to Texas Employment 
Commission, TEC Building, Austin, Texas 
78778 or apply in person at Texas Employ¬ 
ment Commission, San Antonio, Texas J.O. 
#6344795. Ad Paid By Equal Employment 
Opportunity Employer. 
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SYSTEMS ENGINEER 

Systems Engineer needed for information 
management processing firm in Denver, CO 
to analyze data-processing needs of end user 
and improve and extend existing DB2 rela¬ 
tional data base system to meet these needs 
by modifying existing features or adding new 
features, including designing, programming, 
installing, and testing the new requirements 
using PL/I, 370 assembly language, MVS 
internals, PL/AS, QMF, REXX, and CLIST 
methodologies. Write internal and external 
design documents which reflect new require¬ 
ments and design. Requires MS in Compu¬ 
ter Science, MS or Industrial Engineering, 
with specialization in MIS: one year ex¬ 
perience designing and programming DB2 
relational data base system using PL/1 and 
370 assembly language: one year experi¬ 
ence using MVS internals. $45,000/year: 
8:00am -5:00pm. M-F. Respond by resume 
no later than February 1, 1992 to Colorado 
Department of Labor & Employment, Divi¬ 
sion of Employment & Training, 600 Grant. 
Suite 900, Denver. CO 80203, ATT: James 
Shimada, and refer to Job Order No. 
C03773878._ 

DEPAUL UNIVERSITY 
Announcement of Positions in 
Computer Science 

DePaul University invites applications for 
several tenure-track positions in computer 
science at all levels. The starting date is 
September, 1992. Any area of specialization 
will be considered; however, persons in tele¬ 
communications will be given special con¬ 
sideration. Any applicant should hold a 
Ph.D. in computer science or a related field, 
or be a candidate for such a degree. Duties 
include a six-hour teaching load and re¬ 
search. Tenure details and salary are negoti¬ 
able. Benefits include TIAA and standard 
health insurance. U.S. citizenship is not 
required. 

The Department, which offers bachelor's, 
master’s, and doctoral degrees, has over 500 
undergraduate majors and over 800 gradu¬ 
ate students. Facilities include a VAX 6410, 
a VAX 11/750, an IBM 4381, a Harris 
Nighthawk and an AT&T 3B15. Each facul¬ 
ty office is provided with a high performance 
workstation connected to the Department’s 
ethernet. In addition, the Department sup¬ 
ports laboratories in Telecommunications, 
Artificial and Computer Vision and Graphics. 
The Telecommunications lab features an 
AT&T System 75 PBX switch and a variety 
of premise equipment. The Data Communi¬ 
cations lab features PCs connected to thick 
Ethernet,.thin Ethernet, and token ring LAN 
hardware running Novell network operating 
system software. 

In addition, DePaul has recently joined in 
the TERN (Telecommunications Education 
and Research Network) project initiated by 
the University of Pittsburgh. This will (about 
a year from now) provide us access to a 45 
Mbps network connecting over 20 univer¬ 
sities nationwide for telecommunications in¬ 
struction and research purposes. 

The Department's Artificial Intelligence 
Laboratory is equipped with four Hewlett- 
Packard A1 workstations, two Symbolics 
3640s and a Symbolics 3670. The Depart¬ 
ment’s Computer Vision and Graphics 


Laboratory is equipped with an AT&T 
3B2-1000, various graphics workstations in¬ 
cluding a Silicon Graphics Personal Iris, 
assorted graphics terminals including XWin- 
dow terminals, two black and white frame 
grabbers, a 24 bit color frame grabber and a 
dedicated vision processor. There are also 
numerous PC laboratories. 

Faculty interests include telecommunica¬ 
tions, information systems, artificial in¬ 
telligence, computer vision, neural com¬ 
puting, natural languages, applied statistics, 
applied graph theory, computer graphics, 
computer security, compiler design, seman¬ 
tics of programming languages, and com¬ 
puter architecture. 

Applications will be received until posi¬ 
tions are filled. To apply, send a resume and 
at least three letters of reference to Helmut 
Epp, Chairman, Department of Computer 
Science and Information Systems, DePaul 
University, 243 S. Wabash, Chicago, IL 
60604. 

DePaul University is an equal opportunity 
employer. 


NETWORK DESIGN ENGINEER 

Network Design Engineer required. 
Responsible for development, program¬ 
ming, monitoring and analysis of database 
architecture and operating systems including 
support of computer simulation models and 
optimization algorithms, Expert Systems 
(Artificial Intelligence), Neural Networks, 
Database Management Systems, Object 
Oriented Programming, and Numerical An¬ 
alysis. Will utilize C, C + +, Lisp, UNIX, 
Assembler and OS/JCL. Applicants re¬ 
quired to have a Master's Degree or its 
equivalent in Computer Science with at least 
one year experience with UNIX/C, C + + , 
Lisp, UNIX, Assembler, and OS/JCL. Ex¬ 
perience must include prior work with 
analysis of optimization algorithms and 
design of neural networks. Graduate project 
research work in this area will be acceptable. 
An annual salary of $42,000, will be paid for 
a 40-hour work week. Must have proof of 
legal authority to work in the U.S. Interested 
applicants apply at the Texas Employment 
Commission, Ft. Worth, TX, or send resume 
to the Texas Employment Commission, 
Austin, TX 78778-0001, J.O. Number 
6421875. This advertisement was paid by an 
Equal Opportunity Employment Employer. 


CITY COLLEGE OF CUNY 
Computer Sciences Department 

City College invites applications from 
computer scientists committed to both teach¬ 
ing and research, preferably in central areas 
of computer science, e.g., database, operat¬ 
ing systems, computer architecture, tele¬ 
communications, graphics, artificial intelli¬ 
gence, and parallel processing. Applicants 
must have a Ph.D. in computer science or a 
closely related field. Recent Ph.D.’s should 
have research potential and teaching experi¬ 
ence; applicants for associate or full profes¬ 
sorial positions must have an appropriately 
outstanding research and teaching record. 
Positions are open starting with the Fall 
semester of 1992. 

The Department offers the BS and MS 
degrees; the Ph.D. degree is offered in 
cooperation with the CUNY Graduate 


Center. An active research program utilizes 
an extensive array of computing facilities: 
SUN, DEC and Next workstations, STAR- 
DENT 3000 Super Minicomputer, 32-node 
transputer network, and fiber-optic connec¬ 
tions to a University-wide network accessing 
Bitnet, Internet and NYSERnet, among 
others. Laboratories of networked Macintosh 
SE’s, networked 386 PC-compatibles, and 
networked 1PC Sparc Stations also serve the 
students. CCNY and CUNY also support an 
IBM 4381 mainframe and an IBM 3092 vec¬ 
tor processor. 

Position will remain open until a suitable 
candidate can be identified. Salaries: Assis¬ 
tant Professor: $28,630-46,176; Associate 
Professor: $37,308-55,179; Professor: 
$46,310-70,110. 

Applications, with vitae and names of 
three references, should be sent to Professor 
Gary S. Bloom, Chair, Dept, of Computer 
Sciences. 

City College of New York 
Convent Avenue at 138th St, 

New York, NY 10031 
An AA/EO Employer M/F/H/V 


UNIVERSITY OF PITTSBURGH 

Department of Computer Science 

The Department of Computer Science in¬ 
vites applications for one or more tenure- 
track faculty positions beginning with the 
1992-1993 academic year. Candidates at 
the assistant professor level are preferred, 
although applicants with an outstanding 
record in both teaching and research will be 
considered for the rank of associate pro¬ 
fessor. Responsibilities include research, 
supervision of graduate student research 
(Ph.D. and M.S.), and graduate and under¬ 
graduate teaching. Candidates should have 
a Ph.D. in computer science and a strong in¬ 
terest in both teaching and research with a 
research specialization in either operating 
systems or programming languages. Univer¬ 
sity approval of the exact number of posi¬ 
tions available is pending. 

The Department currently has twenty- 
three full-time faculty members and supports 
strong graduate and undergraduate pro¬ 
grams. Departmental resources include an 
excellent research library and extensive com¬ 
puting facilities including a network of SUN, 
DEC and Xerox workstations, an Intel 
iPSC/2 hypercube, a variety of micro¬ 
computers, and several graphics systems. 
The research systems are accessible via the 
Department’s Ethernet-compatible LAN. 
Convenient network access is also provided 
to the extensive general computer facilities of 
the University as well as to other networks 
(e.g., ARPANET, CSNET). Since the Uni¬ 
versity of Pittsburgh is a founding member of 
the Pittsburgh Supercomputing Center and 
an affiliate member of the Software Engi¬ 
neering Institute, the Department of Compu¬ 
ter Science has access to the Cray X-MP/48 
of PSC and the software engineering exper¬ 
tise at SEI. 

Please send resumes to: Dr. Robert P. 
Daley, Chair, Department of Computer Sci¬ 
ence, 322 Alumni Hall University of Pitts¬ 
burgh, Pittsburgh, PA 15260. 

Pitt is an equal opportunity/affirmative 
action employer and especially encourages 
women and members of ethnic minorities to 
apply. 
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SOUTHERN METHODIST UNIVERSITY 
School of Engineering and 
Applied Science 
Department Chair 

Computer Science and Engineering 

Nominations and applications are invited 
for the position of Professor and Department 
Chair of the Department of Computer Sci¬ 
ence and Engineering at Southern Methodist 
University. Applicants must have a Ph.D. in 
Computer Engineering, Computer Science, 
or a related discipline. Candidates must have 
demonstrated excellence in research with a 
substantial grant record and a strong com¬ 
mitment to teaching. It is anticipated that the 
position will be filled by August, 1992. 

SMU is a private university in Dallas, 
Texas with approximately 8,000 students. 
CSE is in the School of Engineering and 
Applied Science, where a close working 
relationship exists with the Department of 
Electrical Engineering. The department is 
growing and presently has fourteen faculty 
positions. CSE presents a balanced program 
of research and education at all levels and 
has been offering Ph.D. degrees since 1970. 
The department has extensive contacts with 
computer and telecommunications related 
industrial organizations. The Dallas area is 
traditionally distinguished as one of the top 
five centers for high technology comple¬ 
mented by the presence nearby of the Super¬ 
conducting Super Collider. 

Applicants should send a complete re¬ 
sume, including the names of three refer¬ 
ences to: 

Professor Ian Gladwell 
Chair, CSE Search Committee 
208 Clements Hall 
Southern Methodist University 
Dallas, TX 75275 

SMU is an equal opportunity/affirmative 
action, Title IX employer. Applications from 
women and minorities are particularly en¬ 
couraged. Applications will be accepted until 
February 1, 1992. 


DATABASE DESIGN ENGINEER 

Database Design Engineer required. 
Design, code, test and implement large data¬ 
base system on IBM Mainframes using 
Adabas as the database language, CICS 
database management system and COBOL 
and NATURAL software. Maintain system 
software and program and code enhance¬ 
ments to system software. Occasional use of 
DB2 and SQL on data conversion projects. 
Applicants required to have an Associates 
Degree or its equivalent in Computers, 
Math, or Engineering with at least three years 
experience in the job duties described above. 
Applicant will only be required to show 
working knowledge of DB2 and SQL (for¬ 
mal training or 3 months experience). Appli¬ 
cant must be willing to relocate every 1 to 2 
years as employer’s needs dictate. Must have 
proof of legal authority to work in the U.S. 
Annual salary will be $43,000 per year for a 
40-hour work week. Interested applicants 
apply at the Texas Employment Commis¬ 
sion, Dallas, TX, or send resume to the 
Texas Employment Commission, Austin, 
TX 78778-0001, J.O. Number 6344563. 
This advertisement was paid by an Equal 
Opportunity Employment Employer. 


SENIOR DESIGN ENGINEER 

Senior Design Engineer needed to design 
and develop local area signalling services 
based switch for telecommunications com¬ 
pany. Conduct high level design for call pro¬ 
cessing switch. Design, implement and test 
software features for digital telecommunica¬ 
tions switch. Provide team leadership for the 
Bulk Calling Line Identification and switch 
based visual services using inband technol¬ 
ogy projects. Monitor completion of activities 
and assume primary contact position for 
project issues. Provide ideas and suggestions 
for future project enhancements. Requires a 
Bachelor’s degree in Computer Science/ 
Computer Engineering and three years ex¬ 
perience in job offered or three years directly 
related digital telecommunications experi¬ 
ence involving software development. Ex¬ 
perience must include at least one year ex¬ 
perience in Pascal as well as End Office 
switch feature development, trunkline ex¬ 
perience and Tanden switch experience. 40 
hour work week. $49,000-72,000 per year. 
Job Order #NC 3010193, DOT Code 
020.061-640. Apply at the Job Service, 516 
North Mengum Street, Durham, North 
Carolina 27701, or your nearest Job Service 
Office. Ad Paid by an Equal Employment 
Opportunity Employer. 


NATIONAL CHIAO TUNG 
UNIVERSITY 
Taiwan, Republic of China 

Applications are invited for faculty posi¬ 
tions in both Department of Computer and 
Information Science and the Department of 
Computer Science and Information Engi¬ 
neering beginning in August 1992. A Ph.D. 
in Computer or Information Science/Engi¬ 
neering or closely related fields is required. 
The University 

National Chiao Tung University is located 
in Hsinchu City near the Science and In¬ 
dustrial Park in Taiwan. It is famous for its 
programs in the areas of Computer Science, 
Computer Engineering, and Electrical Engi¬ 
neering. There are two computer related 
departments in the university, the Depart¬ 
ment of Computer and Information Science 
in Science College and Department of Com¬ 
puter Science and Information Engineering 
in Engineering College. The University 
Computer Center has CONVEX C240 and 
C220 minisupercomputers which are ac¬ 
cessible through FDDI campus network from 
all departments. The Center is the regional 
center of TANet which connects universities 
and research institutes in Taiwan. TANet 
connects to Internet so researchers in Taiwan 
can easily communicate with people in the 
foreign countries. 

Department of Computer and 
Information Science 

The department provides an excellent 
research and teaching environment. Depart¬ 
ment facilities include 20 SUN workstations, 
6 SGI graphics workstations (including one 
VGX340), 15 IBM RS-6000, some SONY 
and DECstations, one 16 nodes nCUBE 
parallel computer, one 16 nodes Trans¬ 
puter, two CONVEX C120 minisupercom¬ 
puters, and many PCs. All computers in the 
Department are interconnected via Ether¬ 
net. The department offers BS, MS, and 


Ph.D. programs. Applicants should have 
strong commitment to teaching graduate 
and undergraduate courses and performing 
research. All areas in Computer Science and 
Computer Engineering are welcome. 

Interested people please send resume and 
names of three references to Professor Wei- 
Pang Yang, Head, Department of Com¬ 
puter and Information Science. National 
Chiao Tung University, Hsinchu, Taiwan, 
Republic of China by the end of February 
1992. 

FAX: (011-886-35) 721-490. 
Department of Computer Science and 
Information Engineering 

The department offers BS, MS, and 
Ph.D. programs. Theory and implementa¬ 
tion of computing systems are both em¬ 
phasized in the department. General pur¬ 
pose computing is provided by a VAX8530, 
two VAX780s, 30 SUN workstations, 10 
IBM RS-6000s, 30 MACs, some HPs, and 
over 150 PCs. Special purpose computing 
facilities include one Sequent S27, three 
transputer networks, one hypercube and 
some IRIS workstations. All computers are 
connected via Ethernet. The department 
also owns the largest nationwide digital 
system laboratory. Special equipment and 
packages for VLSI and digital system design, 
simulation and performance analysis, image 
processing and vision analysis, and software 
engineering are available. Duties of faculty 
members will include teaching undergradu¬ 
ate and graduate courses and performing 
research. The department will give special 
support to new faculty members for starting 
their research. 

The department is particularly interested 
in individuals conducting research in com¬ 
puter system, compiler, computation theory 
and algorithms, DBMS, Multi-media infor¬ 
mation system, and parallel architecture. 
However, qualified candidates in all areas 
will be considered. Interested applicants are 
invited to send a resume and three refer¬ 
ences to Professor Suh-Yin Lee, Head, De¬ 
partment of Computer Science and Informa¬ 
tion Engineering, National Chiao Tung 
University, Hsinchu, Taiwan 300, Republic 
of China by the end of February, 1992. 

FAX: (011-886-35) 724-176. 


RICE UNIVERSITY 

The Department of Electrical and Com¬ 
puter Engineering invites applications for a 
tenure-tract faculty position in the broad area 
of computer systems, to begin in August, 
1992. Applicants must have a doctorate in 
Electrical Engineering, Computer Science or 
Engineering, or a closely related field. 

Rice University is a small, private univer¬ 
sity with a strong commitment to excellence 
in both teaching and research. Rice is located 
in Houston, Texas, a city with affordable 
housing and excellent fine arts. The Depart¬ 
ment of Electrical and Computer Engineer¬ 
ing has close ties with the Department of 
Computer Science. 

Applicants should submit their resume, a 
summary of their research goals and ac¬ 
complishments, and the names of at least 
three references to Chairman. Department 
of Electrical and Computer Engineering, 
Rice University, P.O. Box 1892, Houston, 
Texas 77251. Rice University is an equal op¬ 
portunity/affirmative action employer. 
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CASE INSTITUTE OF TECHNOLOGY 
NORD Prolessorship in 

Computer Engineering and Science 

The Department of Computer Engineer¬ 
ing and Science at Case Institute of Technol¬ 
ogy is seeking a nationally recognized 
scholar and researcher to fill the NORD Pro¬ 
fessorship. This position was recently estab¬ 
lished by the donation of over one and a half 
million dollars, which will provide outstand¬ 
ing professional opportunities and a highly 
competitive salary, together with additional 
funds for travel, graduate student support 
and equipment. The qualifications include a 
Ph.D. in computer science, computer engi¬ 
neering or closely allied fields, and an ability 
to establish and develop external support for 
a nationally recognized research program in 
computer science/computer engineering. 
We encourage applicants in all research 
areas, but our current research thrusts are in 
computer architecture and VLSI design, 
software engineering and systems, database 
systems, and artificial intelligence and logic 
programming. 

CWRU is a private university with a total 
enrollment of 8,400, of which 5,100 are 
graduate and professional students. The 
Engineering School of Case Institute of 
Technology is among the top ten engineer¬ 
ing schools in terms of research funding per 
faculty member and undergraduate student 
quality. The University campus is the hub of 
the pleasant area known as University Circle, 
an incorporation with neighboring cultural 
centers and museums, about five miles from 
downtown Cleveland. 

The Department of Computer Engineer¬ 
ing and Science has 13 faculty positions, and 
a graduate student body of 140 students, 60 
of which are in the Ph.D. program. Depart¬ 
mental facilities are based upon an ethernet 
local area network, connected to INTER¬ 
NET, which supports a UNIX operating sys¬ 
tem and about 40 SUN and other work¬ 
stations. In addition, faculty and students 
participating in the Center for Automation 
and Intelligent Systems Research have ac¬ 
cess to the Center's computing facilities. 

Applicants should submit their curriculum 
vitae and names of at least five references to: 
Lee J. White, Chairman, Department of 
Computer Engineering and Science, 
Case Western Reserve University, Cleve¬ 
land, Ohio 44106: INTERNET: leew@ 
alpha.ces.cwru.edu: applicants may wish to 
provide at most three reprints of their most 
important publications. 

An equal employment and affirmative ac¬ 
tion employer. 


CASE INSTITUTE OF TECHNOLOGY 

Case Western Reserve University 

We invite applications for tenure track 
faculty positions at all levels. Candidates 
from all research areas will be considered, 
but the thrust research areas in the Depart¬ 
ment are VLSI systems and design automa¬ 
tion, applied artificial intelligence and logic 
programming, database design and systems, 
and software systems and design environ¬ 
ments. Candidates should have a Ph.D. in 
computer science or computer engineering 
or closely allied fields: competitive salaries 
will be offered to attract the best candidates. 


CWRU is a private university with a total 
enrollment of 8,400, of which 5,100 are 
graduate and professional students. The 
Engineering School of Case Institute of 
Technology is among the top ten engineer¬ 
ing schools in terms of research funding per 
faculty member and undergraduate student 
quality. The University campus is the hub of 
the pleasant area known as University Circle, 
an incorporation with neighboring cultural 
centers and museums, about five miles from 
downtown Cleveland. 

The Department of Computer Engineer¬ 
ing and Science has 13 faculty positions, and 
a graduate student body of 140 students, 60 
of which are in the Ph.D. program. Depart¬ 
mental facilities are based upon an ethernet 
local area network, connected to INTER¬ 
NET, which supports a UNIX operating 
system and about 40 SUN and other work¬ 
stations. In addition, faculty and students 
participating in the Center for Automation 
and Intelligent Systems Research have ac¬ 
cess to the Center's computing facilities. 

The Department recently acquired the 
Nord Professorship, supported by an en¬ 
dowment, for which we invite distinguished 
senior faculty applicants. The position will 
provide additional funds for travel, graduate 
student support and equipment. 

Applicants should submit their curriculum 
vitae and names of at least three references 
to: Lee J. White, Chairman, Department 
of Computer Engineering and Science, 
Case Western Reserve University, Cleve¬ 
land, Ohio 44106: INTERNET: leew@ 
alpha.ces.cwru.edu; candidates with pre¬ 
vious academic experience may wish to pro¬ 
vide at most three reprints of their most im¬ 
portant publications. 

An equal employment and affirmative ac¬ 
tion employer. 


COLORADO STATE UNIVERSITY 
Faculty Positions, Fall 1992 
Computer Science Department 

The Computer Science Department solic¬ 
its applications for tenure-track and visiting 
faculty positions at all levels (subject to fund¬ 
ing) . Candidates for assistant professor need 
a Ph.D. in computer science (at time of ap¬ 
pointment) with promise for excellence in 
research and teaching; applicants for senior 
ranks must possess distinguished research 
records. The Department has approval for 
significant growth over the next few years, 
and has identified selected areas in parallel 
computing, artificial intelligence, and soft¬ 
ware engineering for special attention. 
Salary is commensurate with rank and ex¬ 
perience. New and visiting faculty will enjoy 
duties especially conducive to productive 

The Department offers B.S., M.S., and 
Ph.D. degrees. We have excellent coopera¬ 
tive research relations with industrial and 
government laboratories, and their people 
form a significant portion of our graduate stu¬ 
dent population. We operate numerous 
multi-user systems (HP, DEC, Sequent) and 
many workstations (HP, IBM, Sun, Apple, 
ATT), all networked. University operations 
include IBM RS6000 servers and a visualiza¬ 
tion laboratory. Department personnel work 
is a pleasant, smoke-free environment. 

Fort Collins is a growing community of 
92,000 located along the foothills of the 


Rocky Mountains, 60 miles north of Denver. 
The climate is moderate—about 15 inches of 
precipitation and 290 days of sunshine per 
year. There are many cultural opportunities 
and year-round outdoor activities. 

Send your curriculum vitae and names of 
at least three professional references to: Dr. 
R.R. Oldehoeft, Search Committee, Com¬ 
puter Science Department, Colorado State 
University, Fort Collins, CO 80523. Appli¬ 
cations for August, 1992 will be considered 
March 1, 1992. The search may be extended 
if suitable candidates are not found. 

Colorado State University is an EEO/AA 
employer. EO Office: 21 Spruce Hall. 


SOFTWARE ENGINEER 

Develop state-of-the-art simulation, 
modelling, and design software product. 
Port current version of software to new plat¬ 
forms (DEC MIPS, Apollo, and DEC Vax 
stations); interface to CASE tools (such as 
IDE’s software through pictures), and data¬ 
base of model inputs and outputs. Develop a 
VHDL interface for the existing state-of-the- 
art simulation, design, and modelling soft¬ 
ware. M.S. in Computer Science or Elec¬ 
trical Engineering required. (Will accept 
completion of all requirements.) Must have 
successfully completed a minimum of one 
course in each of the following: systems 
simulation; data management systems de¬ 
sign; operating systems design: compiling 
system design; integrated circuit systems; 
microprocessors; communications systems. 
Hours are 9:00 a.m. to 6:00 p.m., 40 hours 
weekly, at a monthly salary range of 
$2,988.59-13,500.00, depending on qual¬ 
ifications. Apply at the Texas Employment 
Commission, Austin, Texas, or send resume 
to the Texas Employment Commission, 
TEC Building, Austin, Texas 78778, J.O. 
*6344542. Ad Paid by an Equal Opportu¬ 
nity Employer. 


UNIVERSITY OF WASHINGTON 

Department of Computer Science 
and Engineering 

The Department of Computer Science 
and Engineering at the University of 
Washington expects to have one or more 
tenure-track openings starting in the 
1992-93 academic year. We seek outstand¬ 
ing applicants who add to our existing 
research strengths, particularly in compilers, 
computer systems engineering, and software 
engineering, or who bring significant new 
research strength to our department. 

A moderate teaching load allows time for 
quality research and close involvement with 
students. We expect applicants to have a 
strong commitment to both research and 
teaching, and an outstanding record of 
research for their level. 

Interested applicants should send a letter 
of application, a resume, and the names of 
four references to Faculty Recruiting Com¬ 
mittee, Department of Computer Science 
and Engineering FR-35, University of Wash¬ 
ington, Seattle, Washington 98195. Candi¬ 
dates are encouraged to apply as early as 
possible. 

The University of Washington is an Affir¬ 
mative Action/Equal Opportunity Employer. 
The Ph.D. is required for these positions. 
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SYSTEMS DESIGN ENGINEER 

Systems Design Engineer required. Re¬ 
sponsible for development, programming, 
monitoring and analysis of computer archi¬ 
tecture and computer operating systems 
including support of database systems, com¬ 
pilers, systems simulations, algorithm 
design, numerical analysis, and Object 
Oriented Programming using C, C + + , 
VAX/VMX, Assembler, UNIX, Fortran, 
X-Windows and SQL. Applicants required 
to have a Masters Degree or its equivalent in 
Computer Science with at least one year ex¬ 
perience with UNIX/C, C+ +, VMS/VAX, 
and Assembler. Experience must include 
prior work with design and analysis of op¬ 
timization algorithms, systems simulations 
and with the design of Compiling and Pro¬ 
gramming systems. Graduate project work 
in the area will be considered acceptable. An 
annual salary of $42,000 will be paid for a 
40-hour work week. Must have proof of 
legal authority to work in the U.S. Interested 
applicants apply at the Texas Employment 
Commission, Ft. Worth, TX, or send 
resume to the Texas Employment Commis¬ 
sion, Austin, TX 78778-0001, J.O. Number 
6421879. This advertisement was paid by an 
Equal Opportunity Employment employer. 


UNIVERSITY OF NORTH TEXAS 
College of Arts and Sciences 

Department of Computer Sciences 

Applications are invited for one or two 
tenure-track positions at the assistant or 
associate professor level. Candidates from all 
areas will be considered. A Ph.D. in Com¬ 
puter Science or a related field and a strong 
commitment to both research and teaching 
are required. Salary is competitive. 

With approximately 800 faculty and 
27,000 students (1/3 graduate students), 
UNT is the largest university in north Texas. 
Located 40 miles north of the Dallas/Fort 
Worth metroplex and surrounded by high- 
tech industry, Denton combines a small 
town atmosphere with the advantages of a 
major metropolitan area. The department 
consists of over 20 faculty and offers 
BS/MS/Ph.D. programs to approximately 
150 graduate and 450 undergraduate majors. 

Applicants should send their resumes in¬ 
cluding the names of three references to 
Dr. Robert Renka, Department of Computer 
Sciences, University of North Texas, Den¬ 
ton, TX 76203-3886. 

UNT is an Affirmative Action/Equal Op¬ 
portunity Employer. 


MISSISSIPPI STATE UNIVERSITY 
Professor and Head Electrical and 
Computer Engineering 

Nominations and applications are invited 
for the position of Professor and Head of 
Electrical and Computer Engineering at Mis¬ 
sissippi State University. The Department of 
Electrical and Computer Engineering offers 
ABET accredited undergraduate programs 
and graduate degrees through the doctorate 
in both Electrical Engineering and Computer 
Engineering. It has 26 faculty, 12 profes¬ 
sional and administrative support staff mem¬ 
bers, an undergraduate enrollment of ap¬ 
proximately 560 in electrical engineering 


and 170 in computer engineering, and a 
graduate enrollment of approximately 130 
students. The department has an excellent 
record of scholarly achievement and ranks in 
the top 70 in externally funded research ex¬ 
penditures among Electrical Engineering 
Departments in the U.S., with expenditures 
from externally funded research being ap¬ 
proximately equal to expenditures for edu¬ 
cation. It has a major role in the MSU/NSF 
Engineering Research Center and owns and 
operates the High Voltage Laboratory, a 
unique facility for an educational institution 
in the nation. 

Applicants must hold an earned doctorate. 
They should possess a vision for the future 
directions of Electrical and Computer Engi¬ 
neering and have leadership and managerial 
skills to promote and implement that vision. 
A scholarly record of publications in archival 
literature, conference presentations, and ex¬ 
ternally funded research experience is ex¬ 
pected. The new Head should have teaching 
experience at both the undergraduate and 
graduate levels and must qualify for the rank 
of professor. 

Mississippi State University is a compre¬ 
hensive land grant institution and is among 
the top 100 research-funded institutions in 
the United States as defined by the National 
Science Foundation. The College of Engi¬ 
neering is one of nine colleges/schools in the 
University. The University has 758 faculty 
members and over 13,700 on-campus 
students. 

The Department of Electrical and Com¬ 
puter Engineering is one of eight academic 
departments in the College of Engineering. 
The College has 120 faculty, 2243 under¬ 
graduate and 306 graduate students, and 
funded research expenditures which ex¬ 
ceeded $12 million for FY91. A new Missis¬ 
sippi Research and Technology Park, 
located adjacent to the campus, is con¬ 
tributing greatly to the research programs of 
the college. 

Initial screening of applications will begin 
February 15, 1992, and will continue until 
the position is filled. Send nominations or 
applications and resumes, including names, 
addresses, and telephone numbers of at least 
three references to: 

Dr. John C. McWhorter III 
ECE Search Committee 
Mississippi State University 
P.O. Drawer A 
Mississippi State, MS 39762 

Mississippi State University is an Affir¬ 
mative Action/Equal Opportunity Employer. 


NATIONAL/ADABAS 
SOFTWARE ENGINEER 

National/ADABAS Software Engineer 
required. Feasibility studies, design, devel¬ 
opment, coding, testing and implementation 
of software applications and business infor¬ 
mation systems using Tetrach II/Gold and 
Method/1 methodologies as system design 
tools and Project Manager Workbench and 
Information Engineering Workbench as pro¬ 
ject and resource management tools and 
Natural, Natural/2, Cobol and SWL appli¬ 
cation development languages with IMS, 
DB2 and Adabas databases. Perform system 
analysis, database administration (data 
analysis, normalization, dataflow diagrams, 
data standardization and database manage¬ 


ment), conversion of data and applications 
from Cobol, VSAM, QSAM and IDMS on 
Univac, Sperry, NCR or ICL environments 
to Natural, Natural/2 (Structured and re¬ 
porting modes), SQL, Adabas and DB2 on 
Hitachi and IBM mainframe environments. 
Applicants required to have a Bachelors 
degree or its equivalent in Math, Computers, 
or Engineering with at least one year experi¬ 
ence in the job duties described above. Must 
have proof of legal authority to work in the 
U.S. Annual salary will be $67,000/year for 
a 40-hour work week. Interested applicants 
apply at the Texas Employment Commission, 
Ft, Worth, TX, or Employment Commission, 
Austin, TX 78778-0001, J.O. Number 
6139185. Ad paid by an Equal Employment 
Opportunity Employer. 

OHIO NORTHERN UNIVERSITY 

Department of Mathematics and 
Computer Science 
ADA OH 45810 

The Department of Mathematics and 
Computer Science invites applications for a 
tenure track position in computer science. 
A Ph.D. in computer science or a Ph.D. in 
mathematics with an M.S. in computer sci¬ 
ence is required. ONU is a private, under¬ 
graduate, selective University with colleges 
of Arts and Sciences, Engineering, Business, 
Pharmacy, and Law. Evidence of a commit¬ 
ment to effective undergraduate teaching 
and professional activity is required. Send 
letter, resume, transcripts, and three letters 
of reference to Robert Hovis, Chair, by 
March 1, 1992. Applications will be con¬ 
sidered until the position is filled. ONU is an 
EO/AA employer. Women and minorities 
are encouraged to apply. 

E-mail: hovis@austin.onu.edu. 


GROUP LEADER II 

Direct, coordinate, and exercise func¬ 
tional authority for planning organization 
and integration and completion of engineer¬ 
ing projects involving software design in the 
digital telecommunication switching system. 
Direct technical personnel to design and test 
software in the realtime communication front 
end processor environment and responsible 
for inspection and approval of the design. 
Coordinate the US market design with the 
standard design activities in Sweden and 
perform various Input/Output system in¬ 
vestigations for future developments. Pro¬ 
vide liaison for investigation, evaluation and 
solution of customer problems relating to 
design maintenance, performance and reli¬ 
ability of company’s telephone switching sys¬ 
tem. Define, analyze, and resolve customer 
problems in the switching system and the 
data processing system applying software 
engineering technology. Requires a Bache¬ 
lor’s degree in Computer Science or its 
equivalent and seven years experience in job 
offered or seven years directly related digital 
switching systems experience; or will con¬ 
sider ten years of directly related experience 
in lieu of Bachelor and seven years. 40 hour 
work week. $58,745.00 per year. Apply at 
the Texas Employment Commission, Rich¬ 
ardson, Texas, or send resume to the Texas 
Employment Commission, TEC Building, 
Austin, Texas 78778, Job Order #6599139. 
Ad Paid by an Equal Employment Oppor¬ 
tunity Employer. 
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WAYNE STATE UNIVERSITY 
Chair 

Department of Computer Science 

The Wayne State University Department 
of Computer Science invites applications 
and nominations for the position of Professor 
and Chair. Wayne State University, located 
in Detroit’s Cultural Center, is an urban, 
comprehensive research university serving 
34,000 students. The Department of Com¬ 
puter Science has sixteen faculty members, 
approximately 150 graduate students and 
350 undergraduates. It offers the Ph.D., 
M.S., M.A., B.S., and B.A. degrees. 

The Department has recently moved to 
new quarters with modern laboratory facili¬ 
ties. Current research strengths lie in the 
areas of database systems, software engi¬ 
neering, artificial intelligence, computer 
vision and image processing, distributed 
systems, neural networks, biocomputing, 
numerical methods and natural language 
processing. The faculty have ties to industry 
(including local automotive and computer 
companies) and to several institutes for high 
technology associated with the University. 

The new Chair will be expected to provide 
strong leadership toward enhancing the na¬ 
tional standing of the Department's research 
and teaching programs. Candidates must 
exhibit a distinguished research record, a 
commitment to teaching and strong admini¬ 
strative skills. A Ph.D. in Computer Science 
or a related field is expected. Applications 
from minority and women candidates are 
especially encouraged. Letters of applica¬ 
tion, curriculum vitae and names of at least 
three professional references should be sent 

Dr. Lawrence D. Favro 
c/o George Jones 
Office of the Dean 
College of Liberal Arts 

2226 Faculty Administration Building 
Wayne State University 
Detroit, Ml 48202 

Review of applications will begin on Feb¬ 
ruary 15, 1992, but applications will be ac¬ 
cepted until the position is filled. 

Wayne State University is an Equal Op¬ 
portunity/Affirmative Action Employer. 


COMPUTER CONSULTANT/ 
SYSTEMS ANALYST 

Analyze, code, test and develop data sys¬ 
tems, utilizing multiple programming lan¬ 
guages and multiple technical environments 
including 1BM/MVS/CICS, minicomputer 
and microcomputer. Determine electronic 
data processing system that will provide sys¬ 
tem capabilities to meet clients' require¬ 
ments, and design appropriate new systems 
or modifications to existing systems. Obtain 
data on limitations, capabilities and the 
workload that is proposed. Analyze data to 
determine, recommend and plan computer 
equipment configurations, or modifications 
to the existing equipment and system, to 
provide capability for the proposed project or 
workload, efficient operation and effective 
use of allotted space. Code and test changes 
to various application systems based on the 
clients' needs. Code and unit test new 
modules. Perform systems testing, system 
integration testing and user acceptance. 
Study the existing data handling system (s) to 


evaluate effectiveness and develop new 
systems to make improvements as required. 
Requires a Bachelor's degree in Computer 
Science or its equivalent and three years ex¬ 
perience in job offered or three years directly 
related programming experience utilizing 
knowledge of ‘C. Or will consider a Master’s 
degree in Computer Science and six months 
related programming experience utilizing 
‘C’ language. Background must include one 
semester or six months experience in 
Operating Systems. 40 hour work week. 
$2800.00 per month. Apply at the Texas 
Employment Commission, Dallas, Texas, or 
send resume to the Texas Employment Com¬ 
mission, TEC Building, Austin, Texas 78778. 
Job Order #6422264. Ad paid by an Equal 
Employment Opportunity Employer. 


OREGON GRADUATE INSTITUTE 

The Oregon Graduate Institute is re¬ 
cruiting for a post-doctoral research associate 
in the Department of Computer Science and 
Engineering. Employment may begin any 
time between July 1 and September 30, 
1992 and will last for two years. The suc¬ 
cessful candidate will conduct research in 
query processing for object-oriented data¬ 
bases in conjunction with an existing re¬ 
search group at OGI and groups elsewhere 
in the US. Requirements for the position in¬ 
clude: completion of a Ph.D. in computer 
science prior to the start of employment; top- 
quality academic training in the field of 
database systems, preferably with expertise 
in object-oriented databases and query pro¬ 
cessing; and proven ability to conduct 
research projects in the field of database 
systems. 

OGI is a private research university 
located a few miles west of Portland, 
Oregon. OGI offers graduate degrees only; it 
has no undergraduate program. The De¬ 
partment of Computer Science and Engi¬ 
neering currently has 12 full-time faculty 
members. 

To apply, send a cover letter indicating the 
names of three references and the desired 
starting date, a brief description of research 
interests and a resume to: Philip M. Barrett, 
Department Administrator, Department of 
Computer Science and Engineering, Ore¬ 
gon Graduate Institute of Science & Tech¬ 
nology, 19600 NW von Neumann Drive, 
Beaverton, OR 97006. The closing date for 
applications is March 15, 1992. 

OGI is an Equal Opportunity Employer. 


SYSTEMS DESIGN ENGINEER 

Systems Design Engineer required. Re¬ 
sponsible for development, programming, 
monitoring and analysis of computer ar¬ 
chitecture and computer operating systems 
including support of computer simulation 
models and optimization algorithms, Expert 
Systems (Artificial Intelligence), Networks, 
Database Management Systems, Object Ori¬ 
ented Programming, and Mathematical Pro¬ 
gramming (Numerical Optimization). Will 
utilize C, Pascal, Fortran, Lisp, VAX/VMS, 
UNIX and OS/JCL. Applicants required to 
have a Masters Degree or its equivalent in 
Computer Science with at least one year ex¬ 
perience with UNIX/C, VMS/VAX, AI, 
Fortran, Pascal and Lisp. Experience must 


include prior work with design and analysis 
of optimization algorithms and neural net¬ 
works. Graduate project work in the area will 
be considered acceptable. An annual salary 
of $42,000 will be paid for a 40-hour work 
week. Must have proof of legal authority to 
work in the U.S. Interested applicants apply 
at the Texas Employment Commission, Ft. 
Worth, TX, or send resume to the Texas 
Employment Commission, Austin, TX 
78778-0001, J.O. Number 6421877. This 
advertisement was paid by an Equal Oppor¬ 
tunity Employment employer. 


SOFTWARE ENGINEER 

Software Engineer, 40hrs/wk, 9-6, 
$32,400/yr. Develop test automation by 
host interface and VRU script. Source code 
control under UNIX system. Develop new 
products in voice communication system. 
Design VRU script in IFORM. Maintain and 
develop test report system in INFORMIX. 
Minimum requirements: MS in Computer 
Science. 9 months in software development, 
to include 1/2 year therein in: test support of 
ACD and MIS using various test equipment 
and call generators, in using IFORM under 
OS/2 and IGen under MS DOS developing 
voice processing systems, in development of 
PC to host interface and in programming in 
C, Informix, and dBase. Apply at the Texas 
Employment Commission, Fort Worth, 
Texas, or send resume to the Texas Employ¬ 
ment Commission, TEC Building, Austin, 
Texas 78778, J.O. #6599133. Ad Paid by 
an Equal Opportunity Employer. 


UNIVERSITY OF THE 
WITWATERSRAND, JOHANNESBURG 
Computer Science 
Chair 

AN EXCITING OPPORTUNITY TO 
PARTICIPATE IN A GROWING DEPART¬ 
MENT. Computer Science is a Department 
in the Faculty of Science offering a major 
course within the BSc degree leading to 
Honours, Master's and Ph.D. study. The 
successful applicant will be expected to play 
a fnajor role in the research activities of the 
department. 

Special interest in one or more of the 
following will be an advantage: 

• Theoretical Computer Science 

• Networks and Distributed Systems 

• Computer Graphics 

• Programming Languages 

Salary comparable in purchasing power 
with those at Universities in Western Europe 
and North America. 

There is_glsp a possibility of a salary 
subvention. 

Benefits: Annual bonus, pension, generous 
leave. 100% financial assistance towards 
dependants’ university studies (where appli¬ 
cable) . Housing subsidy, medical aid, reloca¬ 
tion allowance and car scheme (if eligible). 

A limited amount of consulting work is 
permitted. 

Applications, including a detailed curri¬ 
culum vitae and the names and addresses of 
3 referees, should be submitted to the Per¬ 
sonnel Office, University of the Witwater- 
srand, Private Bag 3, Wits 2050, Johannes¬ 
burg, South Africa by 16 March 1992 or fax 
(02711) 339-2223. Quote reference number 
WM 644. 
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NEW YORK UNIVERSITY 

Department of Computer Science 

The Computer Science Department ex¬ 
pects to have several faculty positions avail¬ 
able beginning in September 1992 and in¬ 
vites applications at all levels. Candidates for 
junior positions should show evidence of 
strong research potential and candidates for 
senior positions should have an outstanding 
track record. 

The Computer Science and Mathematics 
departments together form the Courant In¬ 
stitute of Mathematical Sciences, a division 
of New York University. The Computer Sci¬ 
ence Department itself comprises 26 regular 
faculty plus a number of visiting and research 
faculty members. The Department maintains 
a state-of-the-art computing environment 
consisting of well over 100'workstations; in 
addition, specialized research facilities for 
graphics, parallel architectures, robotics, and 
vision are available. 

Substantial funding from AFOSR, DARPA, 
DOE, NIH, NSF, ONR, and from industry 
supports research in a broad array of areas 
including algorithms, artificial intelligence, 
compilers, computer graphics, databases, 
natural languages, numerical analysis, 
parallel architectures and computation, pro¬ 
gramming languages, robotics, software 
engineering, and vision. There are con¬ 
siderable opportunities for collaborative 
research; presently there are joint projects 
with industrial laboratories at AT&T and IBM 
and with the following university depart¬ 
ments/divisions: Biology, Mathematics, 
Physics, Psychology, the Institute for Neural 
Sciences, Medical School, Stern School of 
Business, and the Tisch School of the Arts. 

New York University, the largest private 
university in the country, is located in Green¬ 
wich Village, one of the most attractive 
residential areas of Manhattan. Applications 
should be sent to: Professor Zvi Kedem, 
Chair, Department of Computer Science, 
New York University, 251 Mercer Street, 
New York, NY 10012-1185. 

An Equal Opportunity/Affirmative Action 
Employer. 


UNIVERSITY OF NEVADA 
Computer Science Chair 

The Howard R. Hughes College of Engi¬ 
neering as the University of Nevada, Las 
Vegas invites applicants for the position of 
Chair, Department of Computer Science. In 
addition to administrative and teaching 
duties, the Chair will assist in the develop¬ 
ment of funded research opportunities and 
direct the initiation and development of the 
recently approved Ph.D. program in Com¬ 
puter Science. Applicants- must have a 
Ph.D. in Computer Science, or a closely 
related area, and a distinguished record in 
teaching, research, and service. The appli¬ 
cant must have experience in advising and 
directing doctoral students and be familiar 
with the academic requirements of B.S., 
M. S., and Ph. D. programs in Computer Sci¬ 
ence. Administrative experience at the 
Department or College level is desirable. 

UNLV is a growing university with over 
19,500 students and rapidly expanding 
academic and research programs of state 
and national significance. Engineering and 
computer science programs are housed in the 


new $15,000,000 Thomas T. Beam Engi¬ 
neering Complex. All programs have a 
strong research base with steadily growing 
undergraduate and graduate enrollments. 
Computer Science has ten faculty, 220 
undergraduate and 45 graduate students. 
Faculty are currently active in several spon¬ 
sored research areas including: optical 
character recognition; document storage 
and retrieval; computational geometry 
algorithms; computer graphics applications; 
and simulation. 

The department has modern, well equip¬ 
ped laboratory facilities including: SUN 
SPARC, NeXT, Silicon Graphics 4D, and 
DEC workstations, a Symbolics LISP 
machine, and Intel Hypercube, transputers, 
and an Ethernet Local Area Network. In ad¬ 
dition, faculty have access to a CRAY 
Y-MP2 in the National Supercomputing 
Center for Energy and the Environment 
operated by the College. 

The appointment will begin August 17, 
1992. Applicants should submit a letter of 
application, a complete vita, and the names, 
addresses and telephone numbers of four 
references. Review of applications will begin 
February 1. 1992 and continue until the 
position is filled. Please send applications to: 
Dr. Walter C. Vodrazka, Chair, Computer 
Science Search Committee, Howard R. 
Hughes College of Engineering, University 
of Nevada, Las Vegas, 4505 Maryland Park¬ 
way, Las Vegas, NV 89154. (702) 739-3699. 
E-Mail address: dodgers@UNLV.edu. 
Salary is competitive. 

UNLV is an Equal Opportunity, Affirma¬ 
tive Action Employer and encourages 
women and minorities to apply. UNLV em¬ 
ploys only U.S. citizens and aliens author¬ 
ized to work in the U.S. 


UNIVERSITY OF ILLINOIS 
AT URBANA-CHAMPAIGN 
Center for Supercomputing Research 
and Development 

Postdoctoral Research Associate 
Positions 

The Center for Supercomputing Research 
and Development (CSRD) at the University 
of Illinois at Urbana-Champaign is seeking 
Postdoctoral Research Associates for August, 
1992. Our objective is to provide one- or 
two-year opportunities for young scholars to 
initiate their research careers in an exciting 
and supportive environment. 

Applicants are sought with interests in the 
areas of computational sciences and engi¬ 
neering and parallel computing including: 
parallel algorithms, applications of parallel 
computers to science and engineering, com¬ 
puter architecture and system packaging, 
operating systems, performance evaluation, 
problem-solving environments, and restruc¬ 
turing compilers. Selection will be based 
upon evidence of professional promise, ca¬ 
pacity for independent work, and outstand¬ 
ing achievements to date. Doctoral degree in 
computer science, electrical engineering, or 
a related field is required; degree should be 
received since 1989. 

Appointees will devote most of their ef¬ 
forts to independent research or participate 
in on-going projects. For those interested, 
there may be opportunities to lecture/teach. 

Salaries will be negotiable; appointments 
will be full-time temporary. 

For full consideration, applications should 


be received by March 6, 1992. Interviews 
may take place before the closing date, but 
final decisions will not be made until after 
March 6. Please refer to ad PD91 and send 
application (i.e., a letter of interest and com¬ 
plete Curriculum Vitae, including names, 
addresses and telephone numbers of at least 
3 references) to: 

Ms. Sandy Cunningham 
Center for Supercomputing Research 
and Development 

University of Illinois at Urbana-Champaign 
305 Talbot Lab 
104 S. Wright St. 

Urbana, IL 61801 
Telephone: 217-244-1611 
The University of Illinois is an Affirmative 
Action/Equal Opportunity Employer. 


DIRECTOR OF NETWORK 
INFRASTRUCTURE 

Direct, coordinate and exercise functional 
authority over a group of engineers involved 
in developing and implementing an OEM/ 
Integrater Network-Infrastructure consulting 
service for the United States market. Create 
and document an approved plan for the 
OEM/Integrater sales of services relating to 
cabling, premises distribution systems, fiber¬ 
optic systems, and consulting relating to sale 
of bridges and routers. Develop and imple¬ 
ment procedures and plans for networks in¬ 
frastructure integration, infrastructure engi¬ 
neering methodologies, and project control. 
Determine client, resaler, or VAR require¬ 
ments and develop and implement plans for 
the following: Cabling and Infrastructure 
Service: LAN Construction RFP's; Contrac¬ 
tor Bid Evaluation: Cabling Solutions; Bridg¬ 
ing and Routing System; LAN Installation 
Management; Network Certification. Plan 
and develop long range goals and objectives. 
Review analysis of activities, costs, opera¬ 
tions and forecast data to determine progress 
towards goals and objectives. Requires a 
Master's degree in Computer Science/Tele¬ 
communication or its equivalent and seven 
year's experience in job offered or seven 
years directly related design engineering ex¬ 
perience. 40 hour work week. $53,370.GO- 
75,000.00 per year. Apply at the Texas 
Employment Commission, Dallas, Texas, or 
send resume to the Texas Employment Com¬ 
mission, TEC Building, Austin, Texas 78778, 
Job Order *6599138. Ad Paid by an Equal 
Opportunity Employer. 


ST. MARY’S UNIVERSITY 

Computer Science Faculty Position 

St. Mary's University invites application 
for a tenure-track position in Computer Sci¬ 
ence beginning August 1992. Candidates 
should have an earned Ph D. in CS or re¬ 
lated area and a strong commitment in 
teaching and research. Areas of special in¬ 
terest include AI, SW engineering, and DB. 
Duties would include student advising, grad¬ 
uate and undergraduate courses, working 
■closely with other departments, and univer¬ 
sity service. Applications including vita 
should, be sent to Dr. Doug Hall, Chair, 
Computer Science Dept., St. Mary's Univer¬ 
sity, One Camino Santa Maria, San An¬ 
tonio. Texas 78228-8524. Closing date: 
February 1, 1992. St. Mary's University is an 
EEO/AA employer. 


122 


COMPUTER 











SOFTWARE ENGINEER 

Software Engineer, 40hrs/wk, 8:30-5:30, 
$26,966/yr. Evaluate performance and de¬ 
sign potential modifications on accounting, 
employee leasing and payroll systems using 
Clipper and COBOL/2 in MS-DOS and 
Novell environments. Network manage¬ 
ment of WAN and LAN systems using 
Ethernet protocol and Novell NetWare. 
Design and develop new payroll system 
using COBOL/2 and apply modern soft¬ 
ware engineering concepts in the develop¬ 
ment cycle. Design and develop new em¬ 
ployee leasing applications applied with 
graphical user interface (GUI) technology. 
Provide user support and training. Supervise 
2 programmers in employee leasing and pay¬ 
roll programming. Monitor performance of 
software to locate bottlenecks limiting its per¬ 
formance and improve the execution of the 
software and reconfigure existing hardware, 
if needed. Diagnose and analyze business 
functional needs and implement solutions 
for database management and operating 
systems. Perform unit, integration and vali¬ 
dation testings to have software quality 
assurance and reliability. Minimum require¬ 
ments: MS in Computer Science. 1 year in 
developing payroll systems using COBOL or 
COBOL/2 in MS-DOS environment and in 
implementing Local and Wide Area Net¬ 
works using Novell NetWare. Past develop¬ 
ment of an employee leasing application 
using Clipper. Apply at the Texas Employ¬ 
ment Commission, Dallas, Texas, or send 
resume to the Texas Employment Commis¬ 
sion, TEC Building, Austin, Texas 78778, 
J.O. *'6422241. Ad Paid by an Equal Op¬ 
portunity Employer. 


SOFTWARE ANALYST 

Software Analyst needed to design, 
develop and implement computer software 
for geophysics and geology for a company 
involved in custom computer software 
packages for oil companies. Analyze scien¬ 
tific and engineering data using computer 
techniques and algorithms. Prepare data 
analysis, summaries and reports. Analyze 
computer information systems, procedures, 
and problems to develop well production 
plans and evaluation of oil reserves. Convert 
theoretical concepts, equations, and state¬ 
ments related to the exploration and produc¬ 
tion of gas or oil from well into computer pro¬ 
grams. Design, develop, and implement 
new systems software using VAX/UIS 
graphics and petrophysical and relational 
databases. Requires a Master’s Degree in 
Computer Science and two years in job of¬ 
fered or two years related programming ex¬ 
perience in Unix or Xenix environment. Re¬ 
quires two years experience in the following 
programming languages: C and Basic as well 
as the following operating systems: MS DOS 
and XENIX/UNIX. Must have completed at 
least fifteen credit hours in Statistics, six 
credit hours in Assembly and three credit 
hours in Graphics. 40 hour work week. 
$38,266.00 per year. Apply at the Texas 
Employment Commission, Dallas, Texas, or 
send resume to the Texas Employment 
Commission, TEC Building, Austin, Texas 
78778. Job Order *<6342822. Ad paid by an 
Equal Employment Opportunity Employer. 


ITHACA COLLEGE 

The Department of Mathematics and 
Computer Science at Ithaca College invites 
applications for two tenure-eligible positions 
in computer science. We expect to hire at the 
rank of Assistant Professor, but outstanding 
candidates will be considered at other ranks. 
The appointment will be effective August 15, 
1992. Applicants will be expected to teach a 
wide variety of courses in computer science 
and computer information science. Candi¬ 
dates should possess a Ph.D. in Computer 
Science or a related field by December 1992. 
Screening will begin February 1, 1992. 

Submit letter of application, curriculum 
vita, and three letters of reference, at least 
one addressing teaching, to Dr. David T. 
Brown, Assistant Chair, Department of 
Mathematics & Computer Science, Ithaca 
College, Ithaca, New York 14850. Ithaca 
College is an Affirmative Action/Equal Op¬ 
portunity Employer. 


THE UNIVERSITY OF 
MISSOURI-ROLLA 

The Department of Computer Science at 
the University of Missouri Rolla is seeking 
qualified applicants for tenure track faculty 
positions. Applicants must have a strong in¬ 
terest in theoretical Computer Science. Re¬ 
search experience in theoretical aspects of 
Distributed and Parallel Software Engineer¬ 
ing is a strong plus. Applicants for junior 
positions must demonstrate evidence of their 
ability to perform research and have had 
prior involvement in group research activi¬ 
ties. Applicants for senior positions must 
have a demonstrated record of research and 
funding emphasizing research team leader¬ 
ship as the principal investigator. Course 
load for the first two years is normally one 

The Department grants the B.S., M.S. 
and Ph.D. degrees. The Ph.D. program has 
been active since 1977 and the Department 
currently has 75 graduate students. Depart¬ 
mental funded reseach is growing with yearly 
funding above half a million dollars. Major 
computing facilities include an Intel iPSC/2 
16 processor multicomputer, VAXes, and 
HP equipment in the Departmental Experi¬ 
mental Computation Laboratory, and high- 
function Unix-based workstations for faculty 
and students. Interdisciplinary research ac¬ 
tivities exist in the UMR Intelligent Systems 
Center and faculty members in the Depart¬ 
ment may become Research investigators in 
this Center. 

The University of Missouri Rolla is the 
primary science and engineering campus of 
the University of Missouri system, currently 
has an enrollment of 5000 students, and is 
situated in a non-urban environment in the 
Ozarks. St. Louis is l’/z hours away via inter 
state highway. Salary is competitive with 
Big-10/Big-8 universities. 

Applicants should send a vita plus the 
names of three references and a statement of 
research and teaching interests to: 

Faculty Search Committee 
Department of Computer Science 
University of Missouri-Rolla 
Rolla, MO 65401 
(314) 341-4491 
(csdept@cs.umr.edu) 

An equal opportunity institution. 


OREGON GRADUATE INSTITUTE 

The Oregon Graduate Institute of Science 
& Technology invites applications for a new 
permanent faculty position in the Depart¬ 
ment of Computer Science and Engineering. 
Applicants should have a Ph.D. in computer 
science and 3 or more years of experience in 
research in the area of database systems, 
although exceptional junior candidates will 
be considered. 

OGI is a private research university 
located a few miles west of Portland, 
Oregon. OGI encourages serious scholar¬ 
ship by providing strong administrative sup¬ 
port and excellent research facilities. 
Because OGI offers only graduate degrees, 
faculty have no undergraduate teaching 
responsibilities. The Department currently 
has 12 full-time faculty members. 

It is anticipated that the successful can¬ 
didate will participate in collaborative 
research with Battelle Pacific Northwest 
Laboratories of Richland, Washington in the 
area of scientific information management. 
Supported by the U.S. Department of 
Energy, PNL is expanding the role of com¬ 
puting research in its scientific mission,'par¬ 
ticularly in the fields of environmental and 
molecular sciences. 

To apply, send a brief description of re¬ 
search interests, the names of at least three 
references and a resume to: Professor 
Richard B. Kieburtz, Chairman, Department 
of Computer Science and Engineering, Ore¬ 
gon Graduate Institute of Science & Tech¬ 
nology, 19600 NW von Neumann Drive, 
Beaverton, OR 97006, (503) 690-1150. 
csedept@cse.ogi.edu. 

OGI is an Equal Opportunity Employer. 


VILLANOVA UNIVERSITY 
Tenure-Track Position 

Villanova University invites applications 
for a tenure-track position in computing sci¬ 
ences at the rank of assistant professor. Pref¬ 
erence will be given to those with expertise in 
software engineering or informatics. Appli¬ 
cants with interests in other areas will also be 
considered, especially those working in 
parallel computing or graphics. Applicants 
should have a strong commitment to excel¬ 
lence in teaching and research and an earned 
doctorate in computer science or a closely 
allied discipline. 

The University is located on Philadelphia's 
Main Line, twelve miles west of the center of 
the city. The University offers both the B.S. 
and M.S. degrees in computer science. The 
full-time undergraduate program is accred¬ 
ited by the Computer Science Accreditation 
Commission of the Computing Sciences Ac¬ 
creditation Board. Resources include state- 
of-the-art laboratories and networked work¬ 
stations for information visualization and 
biological systems simulation. 

Candidates should forward their curricu¬ 
lum vitae and three letters of recommenda¬ 
tion to Professor Robert E. Beck, Computing 
Sciences, Villanova University, Villanova, 
PA 19085, Email: beck@vill.edu. Review of 
applications will start February 15, 1992, 
and continue until the position is filled. 
Villanova University is an Augustinian-re- 
lated Roman Catholic institution and is an 
AA/EO Employer. 
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THE UNIVERSITY OF MICHIGAN 
Department of Electrical Engineering 
and Computer Science 

The Department of Electrical Engineering 
and Computer Science at The University of 
Michigan invites applications for positions at 
all levels in its Computer Science and Engi¬ 
neering Division. 

Our emphasis is on the areas of operating 
systems, distributed systems and networks, 
database systems, programming languages, 
software engineering, and theoretical com¬ 
puter science. Exceptional candidates in 
other areas of computer science and engi¬ 
neering will also be considered. All can¬ 
didates who apply should have an interest in 
teaching and a strong research orientation. 

Send your resume and the .names of at 
least three references to Professor Toby J. 
Teorey, Chair of the Faculty Search Com¬ 
mittee, CSE Division, EECS Department, 
The University of Michigan, Ann Arbor, MI 
48109-2122. 

The University of Michigan is an Equal 
Opportunity/Affirmative Action Employer. 


THE CENTER FOR ADVANCED 
COMPUTER STUDIES 
University of Southwestern Louisiana 
Faculty Positions 
Graduate Fellowships 

Candidates with a strong research record 
and earned doctorate in Computer Science 
or Computer Engineering are invited to apply 
for a tenure track senior position available 
starting in Fall 1992. One appointment is 
planned for the rank of Professor. Con¬ 
sideration will also be given to exceptional 
candidates at the Assistant Professor rank. 
Candidates for the senior position must have 
established publications and grant creden¬ 
tials. Consideration will be given to all 
outstanding applicants, but preferred areas 
of interest are software engineering, com¬ 
puter networks, operating systems, data¬ 
bases, computer architecture, artificial in¬ 
telligence, and theoretical computer science, 

Our typical teaching load is two graduate- 
level courses per year and a continuing 
research seminar. Substantial State and Uni¬ 
versity funds are available to support re¬ 
search initiation efforts. Salaries are com¬ 
petitive along with excellent support directed 
towards attainment of faculty professional 
goals. Our colloquium series brings typically 
eight world known professionals to our 
campus each year. 

A number of Ph.D. Fellowships valued at 
up to $18,000 per year including tuition and 
fees are available. They provide support for 
up to four years of study towards the Ph.D. 
in Computer Science or Computer Engi¬ 
neering. Eligible candidates must be U.S. 
citizens or hold an earned MS degree from a 
U.S. or Canadian University. Recipients also 
receive preference for low-cost campus 
housing. 

The Center is a graduate research center 
of 36 faculty and staff with programs leading 
to MS/Ph.D. degrees in Computer Science 
and Computer Engineering. The Center is 
located in Acadiana about 100 miles west of 
New Orleans. The Center has a network of 
70 Sun workstations dedicated for instruc¬ 
tional and research purposes. It also has the 


following five specialized laboratories equip¬ 
ped with state-of-the-art computing facilities: 
VLSI Research; Computer Vision and Pat¬ 
tern Recognition: Intelligent Robotics 
Systems; Software Research; and Artificial 
Intelligence. More than 220 students are 
enrolled in computing graduate programs, 
including over 100 Ph.D. students. The 
undergraduate program in the Computer 
Science Department is accredited by CSAB 
and offers both scientific and commercial op¬ 
tions, with a current enrollment of 280. The 
undergraduate program in the Electrical and 
Computer Engineering Department is ac¬ 
credited by ABET, and offers an option in 
Computer Engineering, with a current en¬ 
rollment of 155. 

To apply, send a copy of your resume and 
the names and addresses of at least three 
professional references to: Dr. Michael C. 
Mulder, The Center for Advanced Compu¬ 
ter Studies, USL, Lafayette, LA 70504-4330; 
Telephone: (318) 231-6284. Applications 
will be considered until all positions are filled. 

An Affirmative Action/Equal Opportunity 
Employer. 


SYSTEMS DESIGN ENGINEER 

Systems Design Engineer required. Re¬ 
sponsible for development, programming, 
monitoring and analysis of computer ar¬ 
chitecture and computer operating systems 
including support of database systems, com¬ 
pilers, systems simulations, algorithm 
design, numerical analysis, and interactive 
graphics using C, VAX/VMX, Assembler, 
UNIX, Fortran, X-Windows and SQL. Ap¬ 
plicants required to have a Masters Degree 
or its equivalent in Computer Science with at 
least one year experience with UNIX/C, 
VMS/VAX, Assembly, X-Windows, For¬ 
tran and SQL. Experience must include 
prior work with analysis of optimization algo¬ 
rithms, design of systems simulations and 
with the design of compiling and program¬ 
ming systems. Graduate project work in the 
area will be considered acceptable. An an¬ 
nual salary of $42,000 will be paid for a 
40-hour work week. Must have proof of 
legal authority to work in the U.S. Interested 
applicants apply at the Texas Employment 
Commission, Ft. Worth, TX, or send 
resume to the Texas Employment Commis¬ 
sion, Austin, TX 78778-0001, J.O. Number 
6421880. This advertisement was paid by an 
Equal Opportunity Employment employer. 


THE UNIVERSITY OF 
RHODE ISLAND 
Assistant Professor, 
Electrical Engineer 

Applications are invited for a tenure-track 
position at the Assistant Professor level in 
Electrical Engineering. The successful can¬ 
didate must be dedicated to teaching at the 
undergraduate and graduate levels and have 
demonstrated their ability to conduct high- 
quality research in their chosen field. Pref¬ 
erence will be given to candidates with a 
background in one of the following areas: 
computer engineering, controls, VLSI or 
high-speed electronics. The successful can¬ 
didate must have completed the require¬ 
ments for a Ph.D. in Electrical or Computer 
Engineering prior to appointment. Review of 


applications will begin on February 3, 1992 
and continue until the position is filled. Send 
your application with the names of three 
references to: Dr. Gabriel Lengyel, Search 
Committee Chair, Position <'081027, THE 
UNIVERSITY OF RHODE ISLAND, P.O. 
Box G, Kingston, RI 02881. An Affirmative 
Action/Equal Opportunity Employer. 


SOFTWARE DESIGN/ 
DEVELOPMENT ENGINEER 

Conduct research, design and develop 
digital switching software features in areas of 
call processing, call processing maintenance, 
mobility management as applicable to digital 
switching system resources, and advanced 
telephony signalling. Conduct high level sys¬ 
tem design and implementation of feature 
development. Research and resolve soft¬ 
ware problems encountered during the pro¬ 
duct/feature verification process. Provide a 
centralized support of the on-site verification 
personnel for the customer. Provide design 
and customer support for digital telecom¬ 
munications switching products. Provide 
technical support as required by design to 
reproduce clarify, and resolve customer 
problems, including testing in the captive of¬ 
fice and on site. Requires a Master’s degree 
in Computer Science or its’ equivalent and 
one year experience in job offered or one 
year digital telecommunications experience. 
Or will consider a Bachelor's degree in Com¬ 
puter Science and two years experience in 
job offered in lieu of the Master's and one 
year experience. Background must include 
at least one year experience in the following: 
Network Systems, Computer Architecture 
(which includes Computer Logic Design), 
Pascal programming language, Communi¬ 
cation Protocols, Call Processing, and Com¬ 
mon Channel Signalling System «7 (CCS7). 
40 hour work week. $47,000.00 per year. 
Apply at the Texas Employment Commis¬ 
sion, Dallas, Texas, or send resume to 
the Texas Employment Commission, TEC 
Building, Austin, Texas 78778. Job Order 
<'6342824. Ad Paid By An Equal Employ¬ 
ment Opportunity Employer. 


SYSTEMS ENGINEER 

Systems Engineer, 40hrs/wk, 9-5 
$2,500/mo. Install/maintain local area net¬ 
works (LANs) including NOVELL & LAN¬ 
TASTIC using ETHERNET & ARCNET 
communication protocols. Design, develop, 
implement, and maintain accounting system 
for company daily control under networking 
environment. Test, evaluate, and trouble¬ 
shoot networking hardware problems for 
IBM compatible 386, 486 system. Install/ 
modify a variety of software including WIN¬ 
DOW, AUTOCAD & VENTURA to meet 
customer needs. Create UNIX & XENIX 
multitasking operating system environments 
for customers. Minimum requirements: MS 
in Computer Science, 9 months in design, 
installation and implementation of NOVELL 
netware, in UNIX & XENIX operating sys¬ 
tems, and in PC hardware troubleshooting, 
9 accounting credit hours. Apply at the 
Texas Employment Commission, Dallas, 
Texas, or send resume to the Texas Employ¬ 
ment Commission, TEC Building, Austin, 
Texas 78778, J.O. <<6422235. Ad Paid by 
an Equal Opportunity Employer. 
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ST. CLOUD STATE UNIVERSITY 
The Department of Computer Science 

The Department of Computer Science in¬ 
vites applicants for one or more tenure-track 
positions beginning September, 1992. 
A Ph.D. in computer science or closely re¬ 
lated field is required. Those who expect to 
finish their Ph.D.’s by the appointment date 
will be considered. The successful candidate 
will be expected to teach a range of courses 
in the department, engage in scholarly activ¬ 
ity and contribute to the growth of the dis¬ 
cipline. The computer science program is 
accredited by CSAB. Salary and benefits are 
competitive. For information and application 
forms, contact Annette D. Schoenberger, 
Chairperson, Department of Computer Sci¬ 
ence, St. Cloud State University, 720-4th 
Avenue South, St. Cloud, MN 56301-4498. 
Applicants should arrange to have at least 
three letters of recommendation sent directly 
to the Chairperson. Review of application 
will begin on February 15, 1992 and will 
continue while a vacancy remains. St. Cloud 
State University is an Equal Opportunity/Af¬ 
firmative Action Employer. Applications 
from women and minorities are particularly 
encouraged. 


SOFTWARE PROGRAMMER 

Design and development of Configuration 
Database management tools in C, Perl, 
Shell, Korn and Bourne programming en¬ 
vironments on the AIX operating system. 
Develop software tools involving system and 
network programming, AIX utilities such as 
MAKE and SCCS for development and 
building of the AIX operating system on the 
IBM RS6000. Maintenance of software tools 
for the preloaded software on the AIX systems 
and automatic updates of IBM RS6000’s 
connected in a local area network using 
TCP/IP protocols. M.S. in Computer Sci¬ 
ence required. (Will accept completion of all 
coursework.) Must have successfully com¬ 
pleted minimum of one graduate-level 
course in each of the following: computer ar¬ 
chitecture; information structures and algo¬ 
rithms; programming language implementa¬ 
tion; software engineering; programming 
languages; operating systems. Flours are 
8:30 a.m. to 5:30p.m., 40 hours weekly, at 
an hourly salary of $23.00. Apply at the 
Texas Employment Commission, Austin, 
Texas, or send resume to the Texas Employ¬ 
ment Commission, TEC Building, Austin, 
Texas 78778, J.O. #6422086. Ad Paid by 
an Equal Opportunity Employer. 


SENIOR OPERATIONS RESEARCH 
ENGINEERS 

Two or more Senior Operations Research 
Engineers required. Conduct research in 
fundamental mathematics and in application 
of mathematical techniques in support of 
design and development of mathematical 
programming, network optimization algo¬ 
rithms and mathematical models in support 
of activities of Operations Research Analysts 
and System Design Engineers. Applies 
mathematics or mathematical methods to 
solution of problems with such techniques as 
mathematical programming inventory con¬ 
trol, queuing theory, sequencing and sched¬ 


uling stochastic modeling. Research, con¬ 
ceptualize and define problem and lead team 
in formulating mathematical or other model 
for automated decision support systems and 
implement solutions in mainframe and micro¬ 
computing environments. Applicants re¬ 
quired to have a Ph.D. in Operations Re¬ 
search with at least one year experience with 
Optimization Algorithms and Mathematical 
Modeling. Applicant must demonstrate one 
year prior experience in the design, creation, 
and implementation of operational computer 
simulation models. An annual salary of 
$45,000 will be paid for a 40-hour work 
week. Must have proof of legal authority to 
work in the U.S. Interested applicants apply at 
the Texas Employment Commission, Ft. 
Worth, TX, or send resume to the Texas 
Employment Commission, Austin, TX 78778- 
0001, J.O. Number 6421882. Ad paid by 
an Equal Employment Opportunity 
employer. 


DATABASE SYSTEM 
SOFTWARE ENGINEER 

Designs and implements major compo¬ 
nents of a state-of-the-art object-oriented 
database system, including query processor, 
and extendible hashing program. Tests cor¬ 
rect operation of database system, measures 
performance of system, ports database sys¬ 
tem to operating systems, builds software 
program that will allow object-oriented data¬ 
base system to work together with network 
database system. MS in Computer Science 
or Computer Engineering and 2 years exper¬ 
ience in computer programming, computer 
engineering, computer science, or computer 
related teaching (academic or employment) 
required. Must have strong background in 
theory and implementation of relational 
database systems, network database systems 
and object-oriented databases. Knowledge 
of MS/DOS and Unix. Strong ability to pro¬ 
gram in C and C++. Good understanding 
of computer software performance evalua¬ 
tion. 1 strong reference. 40 hours per week, 
8:00 a.m. to 5:00 p.m. $35302 per year. 
Apply at the Texas Employment Commis¬ 
sion, Austin, Texas, or send resume to the 
Texas Employment Commission, TEC Build¬ 
ing, Austin, Texas 78778, J.O. #6599117. 
Ad Paid by an Equal Opportunity Employer. 


PURDUE UNIVERSITY 
Computer Engineering 
Faculty Positions 

The School of Electrical Engineering at 
Purdue University seeks outstanding can¬ 
didates in all areas of Computer Engineering 
for research and teaching. Openings are for 
tenure-track faculty at all levels. Active 
research areas include artificial intelligence 
and expert systems; computer architecture; 
computer communications networks; com¬ 
puter vision; design automation tools; digital 
signal processor system design; distributed 
algorithms and databases; fault-tolerant and 
testable computing; microprocessor design; 
natural language processing; neural net¬ 
works; parallel processing (architecture, 
algorithms, operating systems, compiling, 
languages, software environments, intercon¬ 
nection networks, find performance); robot 


vision; software engineering; speech pro¬ 
cessing; and VLSI architecture. 

Applicants must possess a doctorate 
degree. Send a resume, including a state¬ 
ment of teaching and research interests and 
a list of three (3) references, to: Head, 
School of Electrical Engineering, Pur¬ 
due University, West Lafayette, IN 
47907. Purdue University is an Equal Op¬ 
portunity/Affirmative Action employer. 


SYSTEMS DESIGN ENGINEER 

Systems Design Engineer required. Re¬ 
sponsible for development, programming, 
monitoring and analysis of computer ar¬ 
chitecture and computer operating systems 
in support of computer simulation models 
using C, TSO, SAS, X-Windows, VAX/ 
VMS, UNIX and OS/JCL. Will prepare 
technical reports and writings for all systems 
and software developed. Will also design 
and build Object Oriented Graphical User In¬ 
terfaces (GUI). Applicants required to have a 
Masters Degree or its equivalent in Com¬ 
puter Science with at least one year ex¬ 
perience with GUI, UNIX/C, X-Windows 
and VMS/VAX. The applicant will be re¬ 
quired to produce examples of technical 
writings to support proficiency with technical 
writing skills. Graduate project research in 
this area will be acceptable. An annual salary 
of $42,000 will be paid for a 40-hour work 
week. Additional salary up to $48,000 may 
be paid if education and experience warrant. 
Must have proof of legal authority to work in 
the U.S. Interested applicants apply at the 
Texas Employment Commission, Ft. Worth, 
TX, or send resume to the Texas Employ¬ 
ment Commission, Austin. TX 78778-0001, 
J.O. Number 6421876. This advertisement 
was paid by an Equal Opportunity Employ¬ 
ment Employer. 


UNIVERSITY OF NORTH DAKOTA 
Faculty Positions in Computer Science 

Chair: Applications and nominations are 
invited for the position of Chair of the Com¬ 
puter Science Department beginning August 
16, 1992. Qualifications include a Ph.D. in 
computer science or a closely related field, 
accomplishments appropriate for the rank of 
full professor, effective oral and written com¬ 
munication skills, current scholarly activity 
in computer science, and administrative 
competence. 

Assist./Assoc. Professor: Applica¬ 
tions are invited for a tenure-track position in 
the Computer ’Science Department begin¬ 
ning August 16, 1992. Duties include under¬ 
graduate and graduate teaching, research, 
and university service. A Ph.D. in computer 
science or a closely related area is required. 
Applicants should have good communica¬ 
tion skills and broad teaching interests. 
Preference will be given to candidates 
specializing in operating systems, architec¬ 
ture, database systems, or graphics. 

Submit a resume to Dr. Thomas E. O’Neil, 
Search Committee, Department of Com¬ 
puter Science, University of North Dakota, 
Grand Forks, ND 58202-8181. Applications 
will be accepted until March 31, 1992. UND 
is an Affirmative Action/Equal Opportunity 
Employer. 


January 1992 
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UNIVERSITY OF SOUTHWESTERN 
LOUISIANA 
Position Announcement 
Head of Computer Science and 

Associate Director of the Center for 
Advanced Computer Studies 

Applications are invited for the joint posi¬ 
tion of Department Head of Computer Sci¬ 
ence and Associate Director of the Center for 
Advanced Computer Studies. Computer Sci¬ 
ence has been a flagship program at USL 
since the late 1960s. The formation of the 
Center for Advanced Computer Studies at 
USL in the mid-80s extended the program to 
include an international research mission. 
The University enrollment for the Fall 1991 
semester totaled approximately 16,000. 

DESCRIPTION OF THE POSITION: The 
Department of Computer Science is an 
academic unit within the College of Sci¬ 
ences, with five full-time faculty positions, 
seven one-half time instructor positions and 
approximately 400 majors. This Department 
is responsible for administering an excellent 
undergraduate curriculum that has been ac¬ 
credited since 1986. The Center for Ad¬ 
vanced Computer Studies is a separate aca¬ 
demic unit with approximately 200 graduate 
students and 25 graduate faculty. The posi¬ 
tion to be filled reports jointly to the Dean of 
the College of Sciences and the Director of 
the Center for Advanced Computer Studies. 
The incumbent is in a unique position to 
direct an excellent undergraduate computer 
science program and to play an active role in 
the graduate and research programs of the 
Center for Advanced Computer Studies. 
Computer science and engineering labora¬ 
tory facilities include LANs that connect over 
120 Sun workstations, several file servers, 
and an assortment of special laboratories for 
parallel processing, robotics, and VLSI 
design. This position will provide outstand¬ 
ing professional opportunities and a com¬ 
petitive salary. 

QUALIFICATIONS: 

(1) a Ph.D. in computer science or a related 
field; 

(2) credentials to qualify for rank of associate 
or full professor; 

(3) a proven commitment to excellent 
undergraduate and graduate education 
and research; 

(4) proven strong leadership; 

(5) evidence of administrative ability. 

APPLICATION CLOSING DATE: Appli¬ 
cants should send a letter of application con¬ 
taining statements of their academic and ad¬ 
ministrative philosophies; a resume, and 
names of at least three references. For initial 
consideration, applications should be re¬ 
ceived by March 6, 1992. 

Please send applications to: 

Dr. Steve Landry, Chair 
CMPS/CACS Search Committee 
P.O. Box 43610 
Lafayette, LA 70504 
spl@usl.edu 


UNIVERSITY OF DELAWARE 
Computer and Information Sciences 

Are you interested in joining the computer 
science faculty of a dynamic, research 
oriented department in an attractive uni¬ 
versity town within day-trip distance of 


New York, Philadelphia, Baltimore, and 
Washington? 

The University of Delaware, centrally 
located on the East Coast, is recruiting for a 
tenure-track assistant professor position and 
possible visiting faculty positions in the 
Department of Computer and Information 
Sciences. All positions begin September 1, 
1992. 

A Ph.D. degree or its equivalent, and ex¬ 
cellence in research and teaching are re¬ 
quired. Although exceptional applicants in 
all areas of computer science are encouraged 
to apply, special interest exists for tenure- 
track candidates with research expertise in 
architecture, operating systems, or program¬ 
ming languages and compilers. Within these 
areas, research interests in parallel computa¬ 
tion are especially sought. 

The Department offers bachelor, master, 
and doctoral degrees. There are active re¬ 
search groups in artificial intelligence, theory 
of computation, networks, and symbolic 
mathematical computation. These research 
groups include 16 tenure-track faculty and 6 
visiting faculty, along with over 80 graduate 
students, of whom 55 are full-time. Among 
these graduate students, 17 are supported 
by teaching assistantships, 4 by fellowships, 
and 15 by research assistantships. A number 
of these research assistants, and certain 
faculty, are affiliated with the research 
laboratory at the nearby A.l. du Pont 
Institute. 

The Department research facilities include 
various workstations (primarily SUN’s) and 
central computers in a joint research lab 
shared with the Department of Electrical 
Engineering. The latter includes a sixteen 
processor Sequent Symmetry, three VAX 
780’s and various other smaller machines. We 
are well connected to the major networks. 

Candidates should send a curriculum vitae 
to the address given below, along with a 
cover letter indicating whether this is a 
tenure-track or visiting application (or both). 
In addition, candidates should have three 
letters of reference sent directly to: Professor 
Errol L. Lloyd, Recruiting Committee Chair, 
Department of Computer and Information 
Sciences, University of Delaware, Newark, 
DE 19716. For maximum consideration, 
tenure-track applications should be received 
by February 29, 1992, and visiting applica¬ 
tions should be received by April 15, 1992. 

The University of Delaware is an equal op¬ 
portunity, affirmative action employer. Ap¬ 
plications from members of minority groups 
and women are encouraged. 


TULANE UNIVERSITY 

Tulane is a major private university, selec¬ 
tive in enrollment and comprehensive in 
scope, with about 10,000 undergraduate 
and graduate students. The campus is 
located in a residential area of uptown New 
Orleans, one of America's most distinctive 
cities. Faculty benefits include dependent tu¬ 
ition, mortgage assistance, relocation ex¬ 
penses, university contributions of 12% to 
TIAA, and typical insurance benefits. 

The department's computing resources 
includes a network of Sun SPARC worksta¬ 
tions, plus a Pyramid 9815, a 10-program 
Sequent S27 system, and a micro VAX run¬ 
ning VMS. This local area network is a sub¬ 


net of the Tulane University network which 
has a fiber optic backbone and is connected 
to SURANET, a regional subnet of the In¬ 
ternet. Other major computing resources on 
the Tulane University network include a 
Convex C210 supercomputer, several IBM 
RS/6000 systems, and an IBM 3081 main- 

The department invites applications for 
faculty positions in Computer Engineering 
and Computer Science at all levels for the 
fall, 1992. Specialties in Architecture, Soft¬ 
ware Engineering or Neural Nets are prefer¬ 
red, although other specialties will be fully 
considered. A Ph.D. in Computer Science, 
Computer Engineering or a related field is re¬ 
quired, as is research excellence or demon¬ 
strated research potential and a commitment 
to quality teaching is mandatory. In case the 
Ph.D. degree is not yet completed, a suc¬ 
cessful applicant must have completed all re¬ 
quirements for the degree except disserta¬ 
tion within the year prior to selection, with 
expected completion of dissertation prior to 
inception of employment. 

Applications should be directed to Dr. 
Johnette Hassell, Head, Department of 
Computer Science, School of Engineering, 
Tulane University, New Orleans, LA 70118. 
Applications must be received by March 1, 
1992 for fall appointment. Tulane University 
is an Affirmative Action Equal Opportunity 
Employer. 


THE WICHITA STATE UNIVERSITY 
Chairperson 

Computer Science Department 

Applications are invited for the position of 
chairperson of the Computer Science De¬ 
partment. The closing date for applications is 
February 7, 1992 or the first of the month 
thereafter until the position is filled. An¬ 
ticipated starting date is July 1. 1992. 

Required qualifications for the position in¬ 
clude a Ph.D. in Computer Science or a 
closely-related discipline, an established 
record of Computer Science research and 
teaching at a Ph.D. granting department, 
and proven leadership. Salary will be com¬ 
mensurate with qualifications and experience. 

The Computer Science Department has 
approximately 500 undergraduate majors 
and 120graduate students. B.S., B.A., M.S., 
and M.C.S. degrees are currently offered with 
plans underway for offering the Ph.D. 
degree in Computer Science. A primary 
responsibility of the new chairperson will be 
the development of the Ph.D. program. 

The department has 17 full-time faculty 
whose research interests include the areas of 
artificial intelligence, machine learning and 
discovery, automated theorem-proving, 
theoretical computer science, databases, 
logic programming, software engineering, 
programming languages, and simulation 
and modeling. 

Letters of application including a resume 
and names and addresses of at least five 
references should be sent to: Dr. Rajshekhar 
Sunderraman, Chair of the Chair Search 
Committee, Box 83, The Wichita State 
University, Wichita, Kansas 67208. TEL: 
(316) 689-3156. FAX: (316) 689-3770. 
E-Mail: raj@tinman.wsu.ukans.edu. The 
Wichita State University is an Equal Oppor¬ 
tunity/ Affirmative Action Employer. 
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THE FOLLOWING 
INFORMATION IS AVAILABLE: 


PUBLICATIONS AND 
ACTIVITIES 


Contact the Publications Office; 
to facilitate handling, please request by number. 

• Membership application, student #203, others #202 

• Periodicals subscription form for individuals #200 

• Periodicals subscription form for organizations #199 

• Publications catalog #201 

• Compmail electronic mail brochure #194 

• Technical committee list/application #197 

• Chapters lists, start-up procedures #193 

• Student scholarship information #192 

• Volunteer leaders/staff directory #196 

• IEEE senior member grade application #204 
(requires ten years practice and significant performance in five of those ten) 

Tocheck membership status or reportachange of address, callthe IEEE toll-free number, 
1 -&00-678-4333. D i rect all other Computer Society related questions to the Publications 
Office. 



The IEEE Computer Society advances the theory and practice of computer science and 
engineering, promotes the exchange of technical information among 100,000 members 
worldwide, and provides a wide range of services to members and nonmembers. 


Members receive the acclaimed monthly magazine Computer, discounts, and opportu¬ 
nities to serve (all activities are led by volunteer members). Membership is open to all IEEE 
members, affiliate society members, and others interested in the computer field. 


Computer. An authoritative, easy-to-read magazine 
containing tutorial and in-depth articles on topics across the 
computer field, plus news, conferences, calendar, interviews, 
and product reviews. 

Periodicals. The society publishes seven magazines 
and five research transactions. Refer to membership applica¬ 
tion or request information as noted above. 

Conference Proceedings, Tutorial 
Texts, Standard Documents. The Com¬ 
puter Society Press publishes more than 100 titles every year. 
Standards Working Groups. Over 100 of these groups produce IEEE 
standards used throughout the industrial world. 

Technical Committees. Morethan30TCs publish newsletters, provide 
interaction with peers in specialty areas, and directly influence standards, conferences, 
and education. 

Conferences/Education. The society holds about 100 conferences 
each year and sponsors many educational activities, including computing science 
accreditation. 

Chapters. Regular and student chapters worldwide provide the opportunity to 
interact with colleagues, hear technical experts, and serve the local professional 
community. 


Members experiencing problems — magazine delivery, membership status, or 
unresolved complaints — may write to the ombudsman at the Publications Office. 



President: Bruce D. Shriver* 
17 Bethea Drive 
Ossining, NY 10562 
Phone: (914)762-8030 
Fax: (914)941-9181 


nd Tutorials 
VP, Educational Activities 
VP, Membership Activities 
VP, Press Activities 
VP, Publications 
VP, Standards Activities 
VP, Technical Activities 


Barry W. Johnson (1st VP)* 
Raymond E. Miller (2nd VP)* 
Fiorenza C. Albert-Howard* 
Yale N. Patt* 

Harold S. Stone* 

Gary Robinsont 
Joseph Boykin* 


Term Expiring 1992: 

Alicjal. Ellis, Ronald G. Hoelzeman, Tadao Ichikawa, 
C.V. Ramamoorthy, Sallie V. Sheppard, 

Harold Stone, Akihiko Yamada 
Term Expiring 1993: 

Fiorenza Albert-Howard, Jon T. Butler, Michael C. Mulder, 
Yale N. Patt, Anneliese von Mayrhauser, 

Benjamin W. Wah, Ronald Waxman 
Term Expiring 1994: 

Mario R. Barbacci, Luis-Felipe Cabrera, Wolfgang K. Giloi, 
Guylaine M. Pollock, John P. Riganati, Ronald D. Williams, 
Thomas W. Williams 


Secretary: Ronald G. Hoelzeman* 
Treasurer: Laurel V. Kaleda* 

IEEE Division V Director: Bill D. Carroll* 

IEEE Division VIII Director: Helen M. Wood* 
Executive Director: T, Michael Elliott* 
•voting member of the Board ot Governors 
*nonvoting member ot the Board ol Governors 


Next Board Meeting 

February 28,1992,8:30 a.m. 
Cathedral Hill Hotel, San Francisco, CA 


Executive Director: T. Michael Elliott 
Publisher: H. True Seaborn 
Director, Conferences and Tutorials: Anne Marie Kelly 
Director, Finance and Information Services: Tod S. Heisler 
Director, Board and Administrative Services: Violet S. Doan 
Assistant to the Executive Director: Sandra K. Pfau 


Headquarters Office 

1730 Massachusetts Ave. NW 
Washington, DC 20036-1903 
Phone:(202)371-0101 
Fax:(202)728-9614 


Publications Office 

10662 Los Vaqueros Cir. 

PO Box 3014 

Los Alamitos, CA 90720-1264 
Membership and General Information: 
(714)821-8380 

Publication Orders: (800)272-6657 
Fax:(714)821-4010 


European Office 

13, Ave. de L’Aquilon 
B-1200 Brussels, Belgium 
Phone: 32(2)770-21-98 
Fax: 32 (2) 770-85-05 


Asian Office 

Ooshima Building 
2-19-1 Minami-Aoyama, Minato-ku 
Tokyo 107, Japan 
Phone: 81 (3)3408-3118 
Fax: 81 (3) 3408-3553 


President: Merrill W. Buckley, Jr. 
President Elect: Martha Sloan 
Past President: Eric E. Sumner 
Secretary: Karsten E. Drangeid 
Treasurer: Theodore W. Hissey, Ji 


VP, Educational Activities: Edward A. Parrish 
VP, Professional Activities: Arvid G. Larson 
VP, Publication Activities: James T. Cain 
VP, Regional Activities: Luis T. Gandia 
VP, Standards Activities: Marco W. Migliaro 
VP, Technical Activities: Fernando Aldana 










































CALL FOR PAPERS 


Int’l J. on Artificial Intelligence, which 
begins publication this month, seeks pa¬ 
pers emphasizing research, design, devel¬ 
opment, and test of artificial intelligence 
tools and AI tools for old and new knowl¬ 
edge forms. For information and submis¬ 
sion requirements, contact Nikolaos G. 
Bourbakis, SUNY at Binghamton, Electri¬ 
cal Eng. Dept., Binghamton, NY 13902, 
phone (607) 777-2165 or (607) 771-4033, 
fax (607) 777-4822, e-mail bourbaki@ 
bingvaxu.cc.binghamton.edu. 


DCCA 3, Third Working Conf. on 
v*?' Dependable Computing for Critical 
Applications: Sept. 14-16,1992, Mondello, 
Italy. Sponsor: Int’l Federation for Infor¬ 
mation Processing. Submit six copies of pa¬ 
per by Jan. 31,1992, and camera-ready 
version by July 15,1992, to Carl Land- 
wehr, Code 5540, Naval Research Lab, 
Washington, DC 20375-5000, phone (202) 
767-3381, fax (202) 404-7942, e-mail 
Iandwehr@itd.nr.navy.mil. 


Mjb SEKE 92, Fourth Int'l Conf. on Soft- 
'S? ware Eng. and Knowledge Eng.: June 
17-19,1992, Capri, Italy. Cosponsors: Univ. 
of Salerno et al. Submit three copies of full 
paper and 200-word abstract by Jan. 31, 
1992, and camera-ready copy by Apr. 20, 
1992, to Genoveffa Tortora, Dipartimento 
di Informatica ed Applicazioni, Univ. di 
Salerno, 1-84081 Baronissi, Salerno, Italy, 
phone 39 (89) 822-333, fax 39 (81) 482-745, 
e-mail jentor@udsab.dia.unisa.it or 
usditort@inacriai.bitnet. 


10th Software Reliability Symp.: 

viy June 25-26, 1992, Denver. Sponsor: 
IEEE Reliability Soc. Denver Chapter. 
Submit five copies of full paper (maximum 
6,000 words) or extended abstract by Jan. 
31, 1992, and final version by May 1,1992, 
to James Bieman, Computer Science 
Dept., Colorado State Univ., Fort Collins, 
CO 80523, phone (303) 491-7096, e-mail 
bieman@cs.colostate.edu; or Bruce Sand¬ 
ers, Computer Science Dept., Univ. of Col¬ 
orado, Boulder, CO 80309, phone (303) 
492-8118, e-mail sanders@cs.colorado.edu. 


23rd Pittsburgh Conf. on Modeling and 
Simulation: Apr. 30-May 1,1992, Pitts¬ 
burgh. Cosponsors: Univ. of Pittsburgh, 
IEEE et al. Submit two copies of abstract 
and summary by Jan. 31, 1992, and final 
manuscript by May 1,1992, to William G. 
Vogt or Marlin H. Mickle, 348 Benedum 
Eng. Hall, Univ. of Pittsburgh, Pittsburgh, 
PA 15261. 

Annals of Mathematics and Artificial In¬ 
telligence plans a special issue on 2D shape 
analysis in 1992-93. Submit four copies of 
the manuscript by Jan. 31,1992, to Janos 
Csirik, Applied Computer Science Dept., 


Univ. of Szeged, Arpad ter 2., Szeged, H- 
6720 Hungary, e-mail h873csi@ella.uucp or 
h873csi.ella.hu. 

USING 92: May 12-14, 1992, Philadelphia. 
Sponsor: Unix Systems Information Net¬ 
work Group. Submit five copies of 4- to 12- 
page paper by Jan. 31,1992, to Lorenzo 
Bonanni, Bellcore, PYA-2F-216, 6 Corpo¬ 
rate PL, Piscataway, NJ 08854. 


IEEE Trans, on Knowledge and 
Data Eng. plans a special section on 
main-memory databases. Submit six copies 
of 32-page (maximum length) manuscript 
by Feb. 1,1992, and final revised version 
by June 30,1992, to Margaret H. Eich, 
Computer Science and Eng. Dept., South¬ 
ern Methodist Univ., Dallas, TX 75275, 
phone (214) 692-3087, e-mail eich@csvax. 


Call for articles and referees for Computer 


J Computer seeks articles for inclusion in future special issues. 


Computer Support for Concurrent Engineering has been selected as the 
theme for the January 1993 issue. Manuscripts reporting survey, original re¬ 
search, design and development, and applications of computer support for con¬ 
current engineering are sought immediately. See p. 101 of the December 1992 
issue for more details. 

Fourteen copies of the complete manuscript are due by Mar. 15,1992; notifi¬ 
cation of decisions is set for July 15,1992; and the deadline for submittal of the 
final version of each manuscript is Sept. 1,1992. 

Submissions and questions should be directed to K. Srinivas, Drawer 2000, 
Concurrent Engineering Research Center, West Virginia University, 955 Hartman 
Run Rd., Morgantown, WV 26505, phone (304) 293-7226, fax (304) 293-7541, 
e-mail splissue@cerc.wvnet.wvu.edu. 


Multichip modules has been selected as the theme for the April 1993 issue. 
Manuscripts reporting survey, original research, design and development, and 
applications of MCM technology are sought immediately. See p. 101 of the De¬ 
cember 1991 issue for more details. 

A 300-word abstract of the manuscript must be submitted by Apr. 15, 1992; 14 
copies of the full manuscript are due by June 15,1992; notification of decisions 
is set for Oct. 15, 1992; and the deadline for submittal of the final version of each 
manuscript is Dec. 1,1992. 

Submissions and questions should be directed to P.R. Mukund, Dept, of Elec¬ 
trical Eng., Rochester Inst, of Tech., 1 Lomb Memorial Dr., Rochester, NY 14623, 
phone (716) 475-2174, e-mail prmee@ritvax.isc.rit.edu; or J.F. McDonald, Dept, 
of Electrical Eng., Rensselaer Polytechnic Inst., Troy, NY 12180, phone (518) 
276-2919, e-mail mcdonald@unix.cie.rip.edu. 


For submittal to Computer, manuscripts must not have been previously 
published or currently submitted for publication elsewhere. Each manu¬ 
script should be no more than 32 typewritten, double-spaced, single-sided 
pages long, including all text, figures, and references. Each of the 14 cop¬ 
ies submitted should include a title page that contains the title of the arti¬ 
cle, the full name(s) and affiliation(s) of the author(s), complete postal and 
electronic address(es) of all the authors as well as their telephone and fax 
number(s), a 300-word abstract, and a list of keywords identifying the cen¬ 
tral issues of the manuscript’s contents. The final manuscript should be 
approximately 8,000 words in length and contain no more than 12 refer¬ 
ences. 

If you are willing to review articles for any special issue, please send a 
note listing your research interests to Jon T. Butler, editor-in-chief of Com¬ 
puter, at the Dept, of Electrical and Computer Eng., Naval Postgraduate 
School, Code EC/Bu, Monterey, CA 93943-5004, Internet butler@ece. 
nps.navy.mil. 
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Frontiers 92, Fourth Symp. on the 
Frontiers of Massively Parallel Com¬ 
putation: Oct. 19-21,1992, McLean, Va. 
Cosponsors: NASA Goddard Space Flight 
Center et al. Submit workshop and tutorial 
proposals by Feb. 1,1992, to Pearl Wang, 
Computer Science Dept., George Mason 
Univ., Fairfax, VA 22030-4444, phone 
(703) 993-1530, e-mail f92info@gmuvax2. 
gmu.edu; or six copies of paper summary 
by Mar. 2,1992, and camera-ready paper 
by July 1,1992, to H.J. Siegel, Frontiers 92, 
School of Electrical Eng., 1285 Electrical 
Eng. Bldg., Purdue Univ., West Lafayette, 
IN 47907-1285, Internet front92@ecn. 
purdue.edu. 

Electrosoft plans a special issue on expert 
system software for power networks. Sub¬ 
mit four copies of paper by Feb. 1,1992, to 
F.D. Galiana, Electrical Eng. Dept., 

McGill Univ., 3480 University St., Mont¬ 
real, Que. H3A 2A7, Canada. 

Third Int'l Conf. on Algebraic and Logic 
Programming: Sept. 2-4, 1992, Pisa, Italy. 
Submit five copies of 15-page (maximum 
length) manuscript by Feb. 1, 1992, and 
camera-ready version by May 29,1992, to 
Helene Kirchner, CRIN and INRIA-Lor- 
raine, BP 239, Campus Scientifique, 54506 
Vandoeuvre-les-Nancy Cedex, France, 
e-mail hkirchner@loria.crin.fr. 

Int’l J. of Computer Simulation plans a 
special issue on intelligent simulation of 
high-autonomy systems. Publisher: Ablex. 
Submit five copies of full manuscript by 
Feb. 1,1992, to Albert Y. Zomaya, Electri¬ 
cal and Electronic Eng. Dept., Univ. of 
Western Australia, Nedlands, Western 
Australia 6009, fax (619) 380-1065, e-mail 
zomaya@swanee. ee.uwa.oz.au. 

Conpar 92, Int’l Conf. on Parallel Process¬ 
ing, and VAPP V, Vector and Parallel 
Processors in Computational Science: Sept. 
1-4,1992, Lyon, France. Cosponsors: Int’l 
Federation for Information Processing et 
al. Submit manuscript by Feb. 1,1992, to 
Michel Cosnard, Ecole Normale Super- 
ieure de Lyon, Laboratoire de l’lnforma- 
tique du Parallelisme 46, allee d’ltalie, 
69364 Lyon Cedex 07, France, phone (33) 
7272-8037, fax (33) 7272-8080, e-mail 
cosnard@frensl61 .bitnet. 


Fourth Int’l Workshop on Computer-Aid¬ 
ed Verification: June 29-July 1, 1992, Mon¬ 
treal. Submit five copies of 12-page (maxi¬ 
mum length) paper by Feb. 1,1992, to 
G.V. Bochmann, DIRO, Univ. of Mont¬ 
real, 2900 boul. Edouard-Montpetit, CP 
6128, succ. A. Montreal, Que., H3C 3J7 
Canada, fax (514) 343-5834, e-mail 
bochmann@iro.umontreal.ca. 

COGANN, Combination of Genetic Algo¬ 
rithms and Neural Networks Workshop: 

June 6,1992, Baltimore. Sponsor: IEEE 
Neural Networks Council. Submit paper by 
Feb. 1,1992, to Darrell Whitley, Computer 
Science Dept., Colorado State Univ., Fort 
Collins, CO 80523, phone (303) 491-5373, 
e-mail whitley@cs.colostate.edu. 


1992 Int’l Electronics Packaging Conf.: 

Sept. 27-30,1992, Austin, Texas. Sponsor: 
Int’l Electronics Packaging Soc. Submit 
eight copies of 300-word abstract by Feb. 1, 
1992, and final manuscript by July 1,1992, 
to 1992 IEPS Program Committee, 114 N. 
Hale St., Wheaton, IL 60187, phone (708) 
260-1044, fax (708) 260-0867. 

/fWj Computer Security Foundations 

Workshop V: June 16-18, 1992, Fran¬ 
conia, N.H. Submit five copies of full paper 
by Feb. 7,1992, to Ravi Sandhu, ISSE 
Dept., George Mason Univ., Fairfax, VA 
22030-4444, phone (703) 993-1659, e-mail 
sandhu@sitevax.gmu.edu. 

Colt 92, Fifth ACM Workshop on Compu¬ 
tational Learning Theory: July 27-29,1992, 
Pittsburgh. Submit 13 copies of 200-word 
summary by Feb. 10,1992, and final cam¬ 
era-ready version by May 15,1992, to Dav¬ 
id Haussler, Colt 92, Computer and Infor¬ 
mation Sciences, Univ. of California at 
Santa Cruz, Santa Cruz, CA 95064. 

Euro DAC 92, European Design Au- 

tomation Conf.: Sept. 7-10,1992, 
Hamburg, Germany. Cosponsors: IEEE 
Circuit and Systems Soc. et al. Submit 
eight copies of completed manuscript by 
Feb. 14,1992, to MP Associates, Euro 
DAC 92, 7490 Clubhouse Rd., Suite 102, 
Boulder, CO 80301 (for North Am. sub¬ 
missions); Gerald Musgrave, Brunei Univ., 
Electrical Eng. Dept., Kingston Lane, Ux¬ 
bridge, Middlesex UB8 3PH, UK (in Eu¬ 
rope); or Satoshi Goto, NEC, C&C Re¬ 
search Labs, 1-1 Miyazaki, 4-Chome, 
Miyamae-ku, Kawasaki-Shi, Kanagawa 
213, Japan (in Asia). 


VBC 92, Visualization in Biomedical Com¬ 
puting 1992: Oct. 13-16,1992, Chapel Hill, 
N.C. Sponsor: Univ. of North Carolina at 
Chapel Hill. Submit five copies of 1,500- to 
2,000-word extended abstract by Feb. 14, 
1992, to Richard A. Robb, VBC 92, Mayo 
Foundation, Rochester, MN 55905, phone 
(507) 284-4937, fax (507) 284-1632, e-mail 
rar@bru.mayo.edu. 


Second Inti Workshop on Respon- 
sive Computer Systems: Oct. 1-2, 
1992, Saitama, Japan. Sponsor: US Office 
of Naval Research. Submit five copies of 
full manuscript (5,000-word maximum 
length) by Feb. 15,1992, to Hermann Ko- 
petz, Inst, fur Technische Informatik, 
Univ. of Vienna, Treitlstr. 3/182, A-1040 
Wien, Austria, phone 43 (1) 58801-8180, 
fax 43 (1) 569-149, e-mail hk@vmars. 
tuwien.ac.at; or Yoshiaki Kakuda, Infor¬ 
mation and Computer Science Dept., Osa¬ 
ka Univ., 1-1, Machikaneyama-cho, Toyo- 
naka-shi, Osaka, 560, Japan, phone 81 (6) 
844-1151, fax 81 (6) 841-9741, e-mail 
kakuda@ics.osaka-u.ac.jp. 


Third Eurographics Workshop on Render¬ 
ing: May 18-20,1992, Bristol, U.K. Spon¬ 
sor: Univ. of Bristol. Submit four copies of 
extended abstract or e-mailed Latex for¬ 
mat (up to six pages) by Feb. 15,1992, and 
final version by Apr. 17,1992, to Alan 
Chalmers, Computer Science Dept., Univ. 


of Bristol, University Walk, Bristol, BS8 
1TR, UK, phone 44 (272) 303-109, fax 44 
(272) 251-154, e-mail alan@compsci. 
bristol.ac.uk. 


SIGForth 92, ACM SIGForth Workshop: 

Mar. 5-7,1992, Kansas City, Mo. Submit 
abstract of unrefereed paper by Feb. 15, 
1992, and final paper by Mar. 5, 1992, to 
Paul Frenger, PO Box 820506, Houston, 
TX 77282-0506, phone (713) 589-9040, 
GEnie: p.frenger. 

® Ninth IEEE Workshop on Real- 
Time Operating Systems and Soft¬ 
ware: May 13-14,1992, Pittsburgh. Spon¬ 
sor: IEEE Computer Soc. Technical Com¬ 
mittee on Real-Time Systems. Submit 
position statement by Feb. 17,1992, to 
Marc Donner, IBM Research, PO Box 218, 
Yorktown Heights, NY 10598, phone (914) 
784-7508 or (914) 945-2032, fax (914) 945- 
1234. 


VLDB 92,18th Int’l Conf. on Very 
Large Data Bases: Aug. 23-27,1992, 
Vancouver, B.C., Canada. Sponsors: 

VLDB Endowment, Canadian Information 
Processing Soc. Submit six copies of full 
paper (maximum length 5,000 words) by 
Feb. 28,1992, to Alberto Mendelzon, 
Computer Science Dept., Univ. of Toron¬ 
to, 10 King’s College Rd., Toronto, Ont. 
M5S 1A4 Canada, e-mail mendel@db. 
toronto.edu (in the Americas); Erich J. 
Neuhold, IPSI, Dolivostrasse 15, Box 
104326, D-6100 Darmstadt, Germany, 
e-mail neuhold@darmstadt.gmd.de (in Eu¬ 
rope); or Yahiko Kambayashi, IMEL, Fac¬ 
ulty of Eng., Kyoto Univ., Sakyo, Kyoto, 
606-01, Japan, e-mail yahiko@kuis.kyoto- 
u.ac.jp (in the Far East). 


First Int’l Conf. on Computer Comm, and 
Networks: June 8-10, 1992, San Diego, 
Calif. Cosponsors: J. of Computer and Soft¬ 
ware Eng. and/, of High-Speed Networks. 
Submit four copies of full paper by Feb. 28, 
1992, to Kijoon Chae, Computer Science 
Dept., US Naval Academy, Annapolis, 

MD 21402, phone (410) 267-3080, fax (410) 
267-4883, e-mail chae@usna.navy.mil. 

Dexa 92, Third Int’l Conf. on Database 
and Expert Systems Applications: Sept. 2- 
4,1992, Valencia, Spain. Cosponsors: 
Technical Univ. of Valencia et al. Submit 
four copies of paper by Feb. 28,1992, to 
Isidro Ramos, Univ. Politecnica Valencia, 
Sistemas Informaticos y Computacion 
Dept., Apartado 22012, E-46020 Valencia, 
Spain, phone 34 (6) 3877-350, fax 34 (6) 
3877-359, e-mail iramos@dsic.upv.es. 

Int’l J. of Expert Systems: Research and 
Applications plans a special issue on veri¬ 
fication and validation of expert systems, 
especially with regard to applications of 
formal V&V methods. Submit five copies 
of article by Feb. 29, 1992, to Alun D. 
Preece, Computer Science Dept., Concor¬ 
dia Univ., 1455 de Maisonneuve West, 
Montreal, Que. H3G 1M8, Canada, phone 
(514) 848-3014, fax (514) 848-2830, e-mail 
preece@concour.cs.concordia.ca. 
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|^| ISSRE 92, Third Int’l Symp. on Soft- 
ware Reliability Eng.: Oct. 7-9, 1992, 
Research Triangle Park, N.C. Cosponsors: 
IEEE Computer Soc. Technical Commit¬ 
tee on Software Eng. et al. Submit five 
copies of full paper by Mar. 1,1992, and 
camera-ready version by July 15,1992, to 
John C. Munson, Computer Science Div., 
Univ. of West Florida, Pensacola, FL 
32514, phone (904) 474-2989, e-mail 
jmunson@dcsll9.dcsnod.uwf.edu; or Taghi 
M. Khoshgoftaar, Computer Science and 
Eng. Dept., Florida Atlantic Univ., Boca 
Raton, FL 33431, phone (407) 367-3994, 
e-mail taghi@cse.fau.edu. 

OOPSLA 92, Seventh Conf. on Object- 
Oriented Programming Systems, Languag¬ 
es, and Applications: Oct. 18-22,1992, 
Vancouver, B.C., Canada. Sponsor: ACM. 
Submit six copies of full paper by Mar. 1, 
1992, and camera-ready paper by July 20, 
1992, to Rebecca Wirfs-Brock, 16200 SW 
Pacific Hwy., Suite 187, Tigard, OR 97224. 

35th Midwest Symp. on Circuits and Sys¬ 
tems: Aug. 9-12,1992, Washington, DC. 
Cosponsors: George Washington Univ. 
et al. Submit five copies of 500-word sum¬ 
mary by Mar. 1,1992, to Mona E. Zagh- 
loul. Electrical Eng. and Computer Science 
Dept., George Washington Univ., Wash¬ 
ington, DC 20052, phone (202) 994-3772, 
fax (202) 994-0227, e-mail zaghloul@ 
seas.gwu.edu. 

Third Int’l Workshop on VLSI for Artifi¬ 
cial Intelligence and Neural Networks: 

Sept. 2-4, 1992, Oxford, England. Sponsor: 
Univ. of Oxford. Submit 500-word abstract 
by Mar. 1,1992, to Jose G. Delgado-Frias, 
Electrical Eng. Dept., State Univ. of New 
York at Binghamton, Binghamton, NY 
13902-6000, phone (607) 777-4806, fax 
(607) 777-4822, e-mail delgado@bingvaxu. 
cc.binghamton.edu. 

ICMC 92,1992 Int'l Computer Music 
Conf.: Oct. 14-18, 1992, San Jose, Calif. 
Submit paper by Mar. 1, 1992, to ICMC 92, 
Drawer 104, Music Dept., 1 Washington 
Sq., San Jose State Univ., San Jose, CA 
95192-0095, phone (408) 924-4675, fax 
(408) 924-4773, e-mail icms@.sjsuvml. 
bitnet.edu. 


Concur 92, Third Int’l Conf. on Concurren¬ 
cy Theory: Aug. 24-27, 1992, Stony Brook, 
N.Y. Submit paper by Mar. 1,1992, to 
Ranee Cleaveland, Computer Science 
Dept., North Carolina State Univ., Ra¬ 
leigh, NC 27695-8206, phone (919) 515- 
7862, fax (919) 515-7382, e-mail rance@ 


Second European Modula-2 Conf.: Sept. 8- 
9,1992, Leicester, England. Sponsor: 
Leicester Polytechnic. Submit three copies 
of extended abstract by Mar. 9,1992, to 
Sue Brooks, Leicester Polytechnic, Mar¬ 
keting Centre, PO Box 143, Leicester LEI 
9BH, England, fax 44 (0533) 549-972. 


/f|j\ RSP, Third Int’l Workshop on Rapid 
System Prototyping: June 23-25, 
1992, Research Triangle Park, N.C. Co¬ 


sponsors: IEEE Computer Soc. Technical 
Committees on Design Automation, Simu¬ 
lation, and Test Tech. Submit five copies of 
extended summary or full paper (pre¬ 
ferred) by Mar. 10,1992, to Nick Kanopou- 
los. Center for Systems Eng., Research Tri¬ 
angle Inst., 3040 Cornwallis Rd., Research 
Triangle Park, NC 27709, phone (919) 541- 
7341, fax (919) 541-6515, e-mail rsp@rti. 
rti.org. 

11th Symp. on Reliable Distributed 

Systems: Oct. 5-7, 1992, Houston. 
Cosponsors: IEEE Computer Soc. Techni¬ 
cal Committee on Distributed Processing 
et al. Submit five copies of manuscript by 
Mar. 15,1992, and camera-ready paper by 
July 10,1992, to Kishor S. Trivedi, Electri¬ 
cal Eng. Dept., Duke Univ., Durham, NC 
27706, phone (919) 660-5269, e-mail kst@ 
egr.duke.edu. 

Computer-Based Design Environments 
Symp.-Workshop: Aug. 18-19,1992, Ba¬ 
den-Baden, Germany. Submit abstract by 
Mar. 15,1992, and full paper by May 12, 
1992, to Jens Pohl, CAD Research Unit, 

Cal Poly, San Luis Obispo, CA 93407, fax 
(805) 756-5986. 


1992 Classification Soc. of North Am. An¬ 
nual Meeting: June 11-13,1992, East Lan¬ 
sing, Mich. Submit 200-word abstract by 
Mar. 15,1992, to Wayne DeSarbo, Market¬ 
ing and Statistics Depts., School of Busi¬ 
ness, Univ. of Michigan, Ann Arbor, MI 
48109-1234, e-mail wayne_s._desarbo@um. 
cc.umich.edu, Bitnet gegb@umichum. 

J. of Computer and Software Eng. plans a 
special issue in the fall of 1992 on distribut¬ 
ed and parallel computing systems. Submit 
five copies of full manuscript by Mar. 15, 
1992, to Yelena Yesha, Computer Science 
Dept., Univ. of Maryland at Baltimore 
County, Baltimore, MD 21228, phone 
(301) 455-3542, fax (301) 455-3969, e-mail 
yeyesha@algol.umbc.edu. 


(WKj) ASPLOS 5, Fifth Conf. on Architec- 

tural Support for Programming Lan¬ 
guages and Operating Systems: Oct. 12-15, 
1992, Boston. Sponsor: ACM. Submit five 
copies of paper by Mar. 17,1992, and fi¬ 
nal version by July 13,1992, to Hank Levy, 
Computer Science and Eng. Dept., Univ. 
of Washington, Seattle, WA 98195, e-mail 
levy@cs.washington.edu. 

(£§i) ATS 92, First Asian Test Symp.: 

Nov. 26-27, 1992, Hiroshima, Japan. 
Submit five copies of 50-word abstract by 
Mar. 28,1992, and camera-ready copy by 
July 25,1992, to Hideo Fujiwara, Comput¬ 
er Science Dept., Meiji Univ., 1-1-1 Hi- 
gashimita, Tama-ku, Kawasaki 214, Japan, 
fax 81 (44) 934-7912, e-mail fujiwara@cs. 
meiji.ac.jp. 

/gM) Supercomputing 92: Nov. 16-20, 

1992, Minneapolis, Minn. Submit 
manuscript by Apr. 1, 1992, to Ann Hayes, 
Los Alamos Nat’l Lab, Bikini Rd., MS 
B287, Los Alamos, NM 87545, phone (505) 
665-4506, fax (505) 665-4361, e-mail ahh@ 
lanl.gov. 


January 1992 

Conf. on Fullerene Molecules: Scientific 
and Technological Opportunities, Jan. 18- 

23, Tucson, Ariz. Sponsor: Eng. Founda¬ 
tion. Contact Charles V. Freiman, Eng. 
Foundation, 345 E. 47th St., New York, 
NY 10017, phone (212) 705-7835, fax (212) 
705-7441. 

POPL 92,19th ACM Symp. on Principles 
of Programming Languages, Jan. 19-22, 

Albuquerque, N.M. Contact Ravi Sethi, 
AT&T Bell Labs, 600 Mountain Ave., 
Murray Hill, NJ 07974, phone (908) 582- 
7327, e-mail ravi@researc.att.com. 

Technical Symp. on Laser and Sensor 
Eng., Jan. 19-24, Los Angeles. Sponsor: 
Int’l Soc. for Optical Eng. Contact SPIE, 
PO Box 10, Bellingham, WA 98227-0010, 
phone (206) 676-3290, fax (206) 647-1445; 
SPIE, Xantener Strasse 22, D-1000 Berlin 
15, Germany, phone 49 (30) 883-9507, fax 
49 (30) 882-2028; or SPIE, c/o OTO Re¬ 
search, Takeuchi Bldg., 1-34-12 Taka- 
tanobaba, Shinjuku-ku, Tokyo 160, Japan, 
phone 81 (03) 3208-7821, fax 81 (03) 3200- 
2889. 


^ PADS, Sixth Workshop on Parallel 
' and Distributed Simulation, Jan. 20- 

22, Newport Beach, Calif. Joint sponsors: 
IEEE, ACM, Soc. for Computer Simula¬ 
tion. Contact Paul Reynolds, Computer 
Science Dept., Olsson Hall, Univ. of Vir¬ 
ginia, Charlottesville, VA 22903, phone 
(804) 924-1039, e-mail pfr@louisxiv.ipc. 
virginia.edu. 


1992 Usenix Winter Technical Conf., Jan. 
20-24, San Francisco. Contact Usenix Conf. 
Office, 22672 Lambert St., Suite 613, El 
Toro, CA 92630, phone (714) 588-8649, fax 
(714) 588-9706, e-mail conference@usenix. 
org. 


j\ IEEE Int'l Conf. on Wafer-Scale In- 
' tegration, Jan. 22-24, San Francisco. 
Sponsors: IEEE Computer Soc., IEEE 
Components, Hybrids, and Manufacturing 
Tech. Soc. Contact Michael Yung, Hughes 
Research Labs, RL 69, 3011 Malibu Can¬ 
yon Rd., Malibu, CA 90265, phone (310) 
317-5657, fax (310) 317-5484. 


Conf. on Discrete Algorithms, Jan. 27-29, 

Orlando, Fla. Cosponsors: ACM, Soc. for 
Industrial and Applied Math. Contact Bill 
Kolata, SIAM, 3600 University City Sci¬ 
ence Center, Philadelphia, PA 19104-2688, 
phone (215) 382-9800, e-mail siam@ 
wharton.upenn.edu. 


130 


COMPUTER 














CALENDAR 


In the accompanying Calendar and adjoining Call for Papers, the IEEE 
Computer Society logo identifies the conferences the society is sponsoring 
or cooperating in. Other conferences of interest to our readers are also listed. 

The free notices are published in chronological order and as space permits. 

For inclusion in the Call for Papers section, please submit the name of the 
event, date(s), location, sponsor(s), deadline for submittals, and phone and fax 
numbers and — if applicable — the electronic address of the person to whom pa¬ 
pers should be sent. 

For the Calendar section, please provide the event name, date(s), location, 
sponsor(s), and phone and fax numbers and — again, if applicable — the elec¬ 
tronic address of the person to contact for complete information. 

Submitted information should arrive at Computer at least five weeks before 
the month of publication (i.e., for the March 1992 issue, send information for 
receipt by January 20,1992) to Chuck Governale, Calendar Dept., Comput¬ 
er, PO Box 3014, Los Alamitos, CA 90720-1264, fax (714) 821-4010, e-mail 
c.governale @ compmail.com. 


31, Herndon, Va. Cosponsors: IEEE Com¬ 
puter Soc. Technical Committee on Com¬ 
puter Languages, ACM. Contact Patricia 
Orberndorf, NADC Code 7031, Warmin¬ 
ster, PA 18974-5000, phone (215) 441-2737, 
e-mail tricia@nadc.navy.mil. 


February 1992 


RIDE 92, Second Int’l Workshop on 
ns^ Research Issues in Data Eng., Feb. 2- 

3, Tempe, Ariz. Contact Clement Yu, 
EECS Dept., Univ. of Illinois at Chicago, 
Chicago, IL 60680, phone (312) 996-2318, 
fax (312) 413-0024, e-mail yu@uicbert. 


BAST Workshop, Feb. 4-7, Bodega 
vgy Bay, Calif. Cosponsor: Center for 
Reliable Computing. Contact Edward J. 
McCluskey, Center for Reliable Comput¬ 
ing, ERL 460, Stanford, CA 94305-4055, 
phone (415) 723-1451, fax (415) 725-7398. 

Workshop on Object-Oriented Software 
Eng. Practice, Feb. 5-7, Denver. Cospon¬ 
sors: Fujitsu Am. et al. Contact Pankaj 
Goyal, US West Advanced Technologies, 
4001 Discovery Dr., Boulder, CO 80303, 
phone (303) 889-6406, e-mail pankaj@ 

Workshop on Multimedia Information Sys¬ 
tems, Feb. 7-8, Phoenix, Ariz. Contact P. 
Bruce Berra, ECE Dept., Syracuse Univ., 
Syracuse, NY 13244, phone (315) 443-4445. 


1992 IEEE Aerospace Applications Conf., 
Feb. 2-7, Snowmass, Colo. Sponsor: IEEE 
South Bay Harbor Section. Contact Sohrab 
Mobasser, 785 Radcliffe Ave., Pacific Pali¬ 
sades, CA 90272. 


Symp. on Electronic Imaging: Science and 
Tech., Feb. 9-14, San Jose, Calif. Cospon¬ 
sors: Int’l Soc. for Optical Eng., Soc. for 
Imaging Science and Tech. Contact SPIE, 
PO Box 10, Bellingham, WA 98227-0010, 
phone (206) 676-3290, fax (206) 647-1445. 


OFC 92, Conf. on Optical Fiber Comm., 
Feb. 2-7, San Jose, Calif. Cosponsors: 

IEEE Comm. Soc. et al. Contact Optical 
Soc. of Am., 2010 Massachusetts Ave. NW, 
Washington, DC 20036, phone (202) 416- 
1950, fax (202) 416-6140. 

ICDE 92, Eighth Int’l Conf. on Data 
Eng., Feb. 3-7, Tempe, Ariz. Spon¬ 
sor: IEEE Computer Soc. Technical Com¬ 
mittee on Data Eng. Contact Nick J. Cer- 
cone, Center for Systems Sciences, Simon 
Fraser Univ., Burnaby, B.C. V5A 1S6, 
Canada, phone (604) 291-4588 or 3229, fax 
(604) 291-4951, e-mail nick@cs.sfu.ca; or 
(for workshop on research issues) Clement 
Yu, Electrical Eng. and Computer Science 
Dept., Univ. of Illinois at Chicago, Chica¬ 
go, IL 60680, phone (312) 996-2318, fax 
(312) 413-0024. 


Workshop on Field Programmable Gate 
Arrays, Feb. 17-18, Berkeley, Calif. Spon¬ 
sor: ACM Special Interest Group on De¬ 
sign Automation. Contact Jonathan Ross, 
Electrical Eng. Dept., Univ. of Toronto, 10 
King’s College Rd., Toronto, Ont., M5S 
IA4 Canada, phone (416) 978-6992, e-mail 
jayar@eecg.toronto.edu. 

ICICI 92, Int’l Conf. on Intelligent Control 
and Instrumentation, Feb. 18-21, Singa¬ 
pore. Cosponsors: IEEE Singapore Section 
et al. Contact R. Devanathan, IEEE Singa¬ 
pore Section, 200 Jalan Sultan, #11-03 Tex¬ 
tile Centre, Singapore 0719, phone (65) 
291-9690, fax (65) 292-8596, e-mail 
bitnet% “edevan@ntivax”. 

ISSCC 92,1992 IEEE Int’l Solid-State Cir¬ 
cuits Conf., Feb. 19-21, San Francisco. 


Sponsors: IEEE Solid-State Circuits Coun¬ 
cil et al. Contact Diane Suiters, Courtesy 
Associates, 655 15th St. NW, Suite 300, 
Washington, DC 20005, phone (202) 639- 
4255. 

First Japan Information Access Project, 
Feb. 24, Washington, DC. Contact JIAP, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 833-4545, fax 
(202) 728-9614. 

/^jjt Compcon Spring 92, Feb. 24-28, San 

Francisco. Contact Compcon Spring 
92, IEEE Computer Soc., 1730 Massachu¬ 
setts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013, fax (202) 728- 
0884. 


CAAP 92, Colloquium on Trees in Alge¬ 
bra and Programming, and ESOP 92, Eu¬ 
ropean Symp. on Programming, Feb. 24- 

28, Rennes, France. Contact J.-C. Raoult, 
IRISA, Campus de Beaulieu, F-35042 
Rennes Cedex, France, e-mail raoult@ 
irisa.fr (for CAAP 92); or B. Krieg- 
Brueckner, FB3 Mathematik und Informa- 
tik, Universitaet Bremen, Postfach 330 
440, D-2800 Bremen 33, Germany, phone 
49 (421) 218-3660, fax 49 (421) 218-3054, 
e-mail bkb@informatik.uni-bremen.de (for 
ESOP 92). 

11th Int’l Workshop on Distributed Artifi¬ 
cial Intelligence, Feb. 26-28, Glen Arbor, 
Mich. Cosponsors: Univ. of Michigan, In¬ 
dustrial Tech. Inst. Contact Edmund H. 
Durfee, Electrical Eng. and Computer Sci¬ 
ence Dept., Univ. of Michigan, Ann Arbor, 
MI 48109, phone (313) 936-1563, fax (313) 
763-1260, e-mail durfee@caen.engin. 
umich.edu. 


Computer Law Assoc. Conf., Feb. 27-28, 

San Francisco. Contact Barbara Fieser, 
CLA, 8303 Arlington Blvd., Suite 210, 
Fairfax, VA 22031, phone (703) 560-7747, 
fax (703) 207-7028. 


GLS-VLSI 92, Second Great Lakes 
Symp. on VLSI, Feb. 28-29, Kalam¬ 
azoo, Mich. Sponsor: Western Michigan 
Univ. Contact Naveed Sherwani, Comput¬ 
er Science Dept., Western Michigan Univ., 
Kalamazoo, MI 49008, phone (616) 387- 
5662, fax (616) 387-3999. 


March 1992 


1992 ACM/SIGAPP Symp. on Applied 
Computing, Mar. 1-3, Kansas City, Mo. 
Contact Hal Berghel, CAIES, 232 SCEN 
Computer Science, Univ. of Arkansas, 
phone (501) 575-7343, e-mail hlb@uafhp. 
uark.edu. 
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frfi} CAIA 92, Eighth IEEE Conf. on Ar- 
NS?' tificial Intelligence Applications, 
Mar. 2-6, Monterey, Calif. Contact CAIA 
92, IEEE Computer Soc., 1730 Massachu¬ 
setts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013, fax (202) 728- 


/Qjjj Fifth Virus and Security Conf., Mar. 

11-13, New York City. Sponsor: Data 
Processing Management Assoc. Financial 
Industries. Contact Judy S. Brand, PO Box 
6313 FDR Station, New York, NY 10150, 
phone (800) 835-2246 ext. 190, fax (303) 
825-9151. 


/rfji Built-In Self-Test Workshop, Mar. 

18-20, Charleston, S.C. Sponsor: 
IEEE Computer Soc. Technical Commit¬ 
tee on Test Tech. Contact Richard Sed- 
mak, Self-Test Services, 6 Lindenwold 
Terr. Ambler, PA 19002, phone (215) 628- 
9700, fax (215) 628-2106. 


SIGForth 92 Workshop and Seminars, 

Mar. 4-7, Kansas City, Mo. Sponsor: ACM. 
Contact George Shaw, Shaw Labs, PO Box 
3471, Hayward, CA 94540-3471, phone 
(510) 276-5953, fax (510) 276-6050, e-mail 
george_shaw@mts.cc.wayne.edu, Compu¬ 
Serve 70413,2005, GEnie: g.shawl. 

Seventh Computers in Libraries Conf., 
Mar. 4-7, Washington, DC. Contact Mary 
Ellen Cisero, 11 Ferry Ln. W, Westport, 

CT 06880, phone (800) 635-5537 or (203) 
226-6967, fax (203) 454-5840. 

Fuzz IEEE 92, Int’l Conf. on Fuzzy Sys¬ 
tems, Mar. 8-12, San Diego, Calif. Sponsor: 
IEEE Neural Network Council. Contact 
Fuzz IEEE 92, 5665 Oberlin Dr., Suite 110, 
San Diego, CA 92121, phone (619) 453- 
6222, fax (619) 535-3880. 


Int’l Conf. on Computer Applications in 
Design, Simulation, and Analysis, Mar. Il¬ 
ls, Orlando, Florida. Contact G.K.F. Lee, 
Mars Mission Research Center, PO Box 
7910, North Carolina State Univ., Raleigh, 
NC 27695-7910, phone (919) 737-2365, fax 
(919) 737-7968, e-mail glee@maeps0.ncsu. 
edu. 

Hannover Fair Cebit 92, Mar. 11-18, Han¬ 
nover, Germany. Contact Hannover Fairs 
USA, 103 Carnegie Center, Princeton, NJ 
08540, phone (609) 987-1202. 

CPAL 2, Second Regional Workshop on 
Computer Processing of Asian Languages, 
Mar. 12-16, Kanpur, India. Cosponsors: In¬ 
dian Inst, of Tech, et al. Contact R.M.K. 
Sinha, Computer Science and Eng. Dept., 
IIT, Kanpur 208 016, India, e-mail rmk@ 
kalyan.ernet.in. 


ISIF 92, Fourth Int’l Symp. on Integrated 
Ferroelectrics, Mar. 9-11, Monterey, Calif. 
Contact Alona S. Miller, ISIF 92, Micro¬ 
electronics Research Labs, Univ. of Colo¬ 
rado at Colorado Springs, PO Box 7150, 
Colorado Springs, CO 80933-7150, phone 
(719) 593-3488, fax (719) 594-4257. 

CAD and Eng. Workstations 92 and Busi¬ 
ness Graphics 92, Mar. 9-12, Anaheim, 
Calif. Sponsor: National Computer Graph¬ 
ics Assoc., Contact NCGA, 2722 Merrilee 
Dr., Suite 200, Fairfax, VA 22031-4499, 
phone (800) 225-NCGA or (703) 698-9600, 
fax (703) 204-4521. 

Third Int’l Conf. on Data and 

Knowledge Systems for Manufactur¬ 
ing Eng., Mar. 9-13, Villeurbanne, France. 
Cosponsors: Assoc. Francaise pour la Cy- 
bernetique Economique et Technique et 
al. Contact INSA, 20 Av. Albert Einstein, 
69621 Villeurbanne, France, phone 33 (72) 
438-172, fax 33 (72) 440-800. 

Fourth Int’l Conf. on Strategic Soft- 

ware Systems, Mar. 10-11, Hunts¬ 
ville, Ala. Cosponsors: IEEE Computer 
Soc. Huntsville Chapter, Univ. of Alabama 
in Huntsville. Contact Ann H. Yelle, Univ. 
of Alabama in Huntsville, Continuing Edu¬ 
cation Div., Conferences (SSS-92), Bevill 
Center 289-A, Huntsville, AL 35899, 
phone (800) 448-4035 or (205) 895-6372, 
fax (205) 895-6934 or 6760. 

ISQE 92, Int'l Software Quality Exchange, 
Mar. 10-11, San Francisco. Sponsor: Juran 
Inst. Contact Brian T. Eck, Juran Inst., 11 
River Rd., PO Box 811, Wilton, CT 06897- 
0811, phone (800) 338-7726. 

Lyon Conf., Mar. 10-12, Lyon, France. 
Contact Solange Dubeauclard, 1030 N. 
Glenhurst, Birmingham, MI 48009, phone 
(313) 647-7833. 


Symp. on Document Analysis and Infor¬ 
mation Retrieval, Mar. 16-18, Las Vegas, 
Nev. Contact William L. Brogan, Electrical 
Eng. Dept., Univ. of Nevada at Las Vegas, 
4505 Maryland Pkwy., Las Vegas, NV 
89154, phone (702) 597-4184, e-mail 
eewlb@cs.unlv.edu; or Kazem Taghva, 
Computer Science Dept., UNLV, 4505 
Maryland Pkwy.. Las Vegas, NV 89154, 
phone (702) 739-3338, e-mail taghva@cs. 
unlv.edu. 


EDAC 92, European Conf. on De- 
vU' sign Automation, Mar. 16-19, Brus¬ 
sels. Cosponsors: EDAC Assoc, et al. Con¬ 
tact Herman Beke, EDC Abdisstraat 34, 
3030 Leuven-Heverlee, Belgium, phone 32 
(16) 20-3063; or EDAC 92 Secretariat, 

CEP Consultants, 26-28 Albany St., Edin¬ 
burgh EH1 3QH, UK, phone 44 (31) 557- 
2478, fax 44 (31) 557-5749. 


Int’l Zurich Seminar on Digital Communi¬ 
cations, Mar. 16-19, Zurich, Switzerland. 
Contact Walter Schlegel, Ascom Tech, 
Freiburgstr. 370, CH-3018 Berne, Switzer¬ 
land, phone 41 (31) 632-136, fax 41 (31) 
555-211, e-mail schlegel@tech.ascom.ch. 


Packaging, Interconnects, Optoelec- 
tronics for the Design of Parallel 
Computers, Mar. 17-18, Schaumberg, Ill. 
Sponsor: IEEE Lasers and Electro-Optics 
Soc. Contact Jose Schuh-Aine or Raj Mit- 
tra, Univ. of Illinois, 1406 W. Green St., 
Urbana, IL 61801-2991, phone (217) 244- 
7279, fax (217) 333-8986. 


IEEE Multi-Chip Module Conf., 
Mar. 17-20, Santa Cruz, Calif. Co¬ 
sponsors: IEEE Circuits and Systems Soc. 
et al. Contact Wayne Wei-Ming Dai, 313A 
Applied Sciences Bldg., Computer Eng. 
Dept., Univ. of California, Santa Cruz, CA 
95064, phone (408) 459-4234, fax (408) 
459-4829. 


Second Conf. on Computers, Freedom, 
and Privacy, Mar. 18-20, Washington, DC. 
Cosponsors: ACM et al. Contact Confer¬ 
ences and Institutes Office, George Wash¬ 
ington Univ., Washington, DC 20052, 
phone (202) 994-0723, fax (202) 994-7048, 
e-mail cfp2@seas.gwu.edu. 

(£§i) EDBT 92, Int’l Conf. on Extending 
Database Tech., Mar. 23-27, Vienna. 
Sponsor: IEEE. Contact Brigitte Haber- 
stroh, Inst. 184-2, Tech. Univ. of Vienna, 
A-1040 Vienna, Austria, phone 43 (1) 588- 
01/6122, fax 43 (1) 505-5304. e-mail 
haberstroh@vexpert.dbai.tuwien.ac.at. 

DCC 92, Data Compression Conf., 
Mar. 24-26, Snowbird, Utah. Spon¬ 
sors: IEEE Computer Soc. Technical Com¬ 
mittee on Computer Comm., NASA. Con¬ 
tact Martin Cohn, Computer Science 
Dept., Brandeis Univ., Waltham, MA 
02554, phone (617) 736-2705, fax (617) 
736-2741, e-mail marty@cs.brandeis.edu. 

1992 Computer-Based Systems Eng. 
Workshop, Mar. 24-26, Washington, 
DC. Sponsor: IEEE Computer Soc. Task 
Force on Computer-Based Systems Eng. 
Contact Ashok Agrawala or Phil Hwang, 
Computer Science Dept., Univ. of Mary¬ 
land, College Park, MD 20742. 

SEDMS 92, Third Symp. on Experi- 
ences with Distributed and Multipro¬ 
cessor Systems, Mar. 26-27, Newport 
Beach, Calif. Sponsor: Usenix Assoc. Con¬ 
tact George Leach, AT&T Paradyne, MS 
LG-133, PO Box 2826, Largo, FL 34649- 
2826, phone (813) 530-2376, fax (813) 530- 
8224, e-mail reggie@pdn.paradyne.com. 

ASOM, Second Am. Symp. on Mi- 
croelectronics. Mar. 27-28, Memphis, 
Tenn. Sponsor: Memphis State Univ. Con¬ 
tact Eliayeb S. Abuelyaman, Electrical 
Eng. Dept., Memphis State Univ., Mem¬ 
phis, TN 38152, phone (901) 678-2050, fax 
(901) 678-4180. 

(gj!) IPPS 92, Sixth Int’l Parallel Process- 
nIJ' ing Symp., Mar. 30-Apr. 2, Beverly 
Hills, Calif. Contact Larry H. Canter, 
Computer Systems Approach, 1140 S. Ray¬ 
mond Ave., Suite B, Fullerton, CA 92631, 
phone (714) 738-3414, fax (714) 738-3470. 


April 1992 

(gjj) PCCC 92, nth IEEE Int’l Phoenix 
Conf. on Computers and Communi¬ 
cations, Apr. 1-3, Scottsdale, Ariz. Cospon¬ 
sors: IEEE Comm. Soc. et al. Contact 
Ralph Martinez, Univ. of Arizona, Electri¬ 
cal and Computer Eng. Dept., Tucson, AZ 
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85721, phone (602) 621-6174, e-mail 
martinez%ecevax@rvax.ccit.arizona.edu; 
or Joseph Urban, Computer Science and 
Eng. Dept., Arizona State Univ., Tyler 
Mall-ECG 252, Tempe, AZ 85287-5406, 
phone (602) 965-2774, fax (602) 965-2751, 
e-mailjurban@asuvax.eas.asu.edu. 

10th IEEE VLSI Test Symp., Apr. 
7-9, Atlantic City, N.J. Sponsor: 

IEEE Computer Soc. Technical Commit¬ 
tee on Test Tech. Contact IEEE Computer 
Soc., 1730 Massachusetts Ave. NW, Wash¬ 
ington, DC 20036-1903, phone (202) 371- 
1013, fax (202) 728-0884; or Dhiraj Prad- 
ham, Univ. of Massachusetts, ECE Dept., 
Marcus Hall, Amherst, MA 01003, phone 
(413) 545-0160, fax (413) 545-4611. 

Third Workshop on Future Trends in 
Distributed Computing, Apr. 14-16. 

Sponsor: IEEE Computer Soc. Technical 
Committee on Distributed Computing. 
Contact Stephen S. Yau, Univ. of Florida, 
Computer and Information Sciences Dept., 
301 CSE Bldg., Gainesville, PL 32611- 
2024, phone (904) 392-1212, fax (904) 392- 
1220. 

(£fj\ ICCL 92, Int’l Conf. on Computer 
viz Languages, Apr. 20-23, San Fran¬ 
cisco. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Computer Languages. 
Contact Mario Barbacci, Software Eng. 
Inst., Carnegie Mellon Univ., Pittsburgh, 
PA 15213, phone (412) 268-7704, fax (412) 
268-5758, e-mail barbacci@sei.cmu.edu. 

Third Workshop on Workstation Op- 
erating Systems, Apr. 23-24, Key 

Biscayne, Fla. Sponsor: IEEE Computer 
Soc. Technical Committee on Operating 
Systems and Applications Environments. 
Contact Joseph Boykin, 7 Hampton Rd., 
Natick, MA 01760, phone (508) 651-8228. 


May 1992 


CHI 92, Conf. on Human Factors in 
Computing, May 3-7, Monterey, 

Calif. Sponsor: ACM. Contact Assoc, for 
Computing Machinery, 11 W. 42nd St., 
New York, NY 10036, phone (212) 869- 
7440. 

(gjj) 1992 IEEE Symp. on Research in Se- 
curity and Privacy, May 4-6, Oak¬ 
land, Calif. Sponsor: IEEE Computer Soc. 
Technical Committee on Security and Pri¬ 
vacy. Contact Deborah Cooper, Unisys, 
5731 Slauson Ave., Culver City, CA 90230, 
phone (310) 338-3727, e-mail cooper@culv. 
unisys.com. 

IEEE Infocom 92, Uth Conf. on 
Computer Comm., May 4-8, Flo¬ 
rence, Italy. Cosponsor: IEEE Comm. Soc. 
Contact L. Fratta, Politecnico di Milano, 
c/o Cefriel, Via Emanueli, 15, 20126 Mila¬ 
no, Italy, phone 39 (2) 2399-3578, fax 39 
(2) 2399-3587, e-mail fratta@imicefr.bitnet; 
or J. Kurose, Computer and Information 


Science Dept., Univ. of Massachusetts, 
Amherst, MA 01003, phone (413) 545- 
1585, e-mail kurose@cs.umass.edu. 

CompEuro 92, IEEE Int'l Conf. on 
viz Computer Systems and Software 
Eng., May 4-8, The Hague, The Nether¬ 
lands. Cosponsors: IEEE Region 8, IEEE 
Benelux Section. Contact Patrick Dewilde, 
Delft Univ. of Tech., EE Dept., POB 5031, 
2600 GA Delft, The Netherlands, fax 31 
(15) 623-271; or G. Arink, Philips Medical 
Systems, PO Box 10000, 5680 DA Best, 

The Netherlands, phone 31 (40) 762-060, 
fax 31 (40) 762-952. 

(gi) PTW 92, Second Pacific Test Work- 
shop, May 5-8, Vancouver, B.C., 
Canada. Sponsor: IEEE Computer Soc. 
Technical Committee on Test Tech. Con¬ 
tact Andre Ivanov, Electrical Eng. Dept., 
Univ. of British Columbia, 2356 Mian 
Mall, Vancouver, B.C. V6T 1Z4, Canada, 
phone (604) 822-6936, fax (604) 822-5949; 
or Mani Soma, phone (206) 685-3810, fax 
(206) 543-3842. 

1992 IEEE Int'l Conf. on Robotics and 
Automation, May 10-15, Nice, France. 
Sponsor: IEEE Robotics and Automation 
Soc. Contact Harry Hayman, PO Box 3216, 
Silver Spring, MD 20918, phone (301) 236- 
5621, fax (301)236-5621. 

|gi) ICSE 92,14th Int’l Conf. on Soft- 
^tz ware Eng., May 11-15, Melbourne, 
Australia. Cosponsors: IEEE Computer 
Soc. Technical Committee on Software 
Eng. et al. Contact IEEE Computer Soc., 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013, fax 
(202) 728-0884; or A.Y. Montgomery, 
Computer Science Dept., Royal Mel¬ 
bourne Inst, of Tech., PO Box 2476V, Mel¬ 
bourne 3001, Victoria, Australia, phone 61 
(3) 660-2943, fax 61 (3) 662-1617, e-mail 
aym@goanna.cs.rmit.oz.au. 

USING 92, May 12-14, Philadelphia. Spon¬ 
sor: Unix Systems Information Network 
Group. Contact Don Ackerson, USING, 
PO Box 1077, Lisle, IL 60532, phone (708) 
896-5777. 

(gj!) Ninth IEEE Workshop on Real- 
v=Z Time Operating Systems and Soft¬ 
ware, May 13-14, Pittsburgh. Sponsor: 
IEEE Computer Soc. Technical Commit¬ 
tee on Real-Time Systems. Contact Marc 
Donner, IBM Research, PO Box 218, 
Yorktown Heights, NY 10598, phone (914) 
784-7508 or (914) 945-2032, fax (914) 945- 
1234. 

|gj\ Workshop on Interconnections with- 
vAz in High-Speed Digital Systems, May 
18-20, Santa Fe, N.M. Sponsor: IEEE La¬ 
sers and Electro-Optics Soc. Contact Ken 
Young, Bellcore, 445 South St., Rm. 2Q- 
150, Morristown, NY 07962-1910. 

(gi) ISC A 92, 19th Int’l Symp. on Com- 
vAz puter Architecture, May 19-21, 

Queensland, Australia. Cosponsors: IEEE, 
ACM SIGArch. Contact Jean-Lue Gaudi- 
ot, EE-Systems Dept., SAL 300, Univ. of 


Southern California, Los Angeles, CA 
90089-0781, phone (213) 740-4484 or (213) 
743-0249, fax (213) 740-4449, e-mail 
gaudiot@usc.edu or gaudiot@priam.usc. 
edu; or D. Abramson, CSIRO, 723 Swan- 
ston St., Melbourne 3000, Australia, phone 
61 (3) 282-2666, e-mail david.abramson@ 
mel.dit.csiro.au. 

/gj\ Sixth Int’l Conf. on Computer Sci- 
^Az ence. May 20-22, Tunis, Tunisia. 
Sponsor: Assoc. Francaise pour la Cyber- 
netique Economique et Technique. Con¬ 
tact Montasser Ouaili, Ecole Nationale des 
Sciences de l’lnformatique, 16 Rue 8010 
Quartier Montplaisir, 1002 Tunis Belve¬ 
dere, Tunisia, phone 216 (1) 784-032, fax 
216(1)787-827. 

(g^| Israeli Symp. on the Theory of Com- 
^Az puting and Systems, May 27-28, Hai¬ 
fa, Israel. Cosponsors: Assoc, of Techno¬ 
logical Education in Electronics and Com¬ 
puter Science et al. Contact Michael 
Rodeh, Science and Tech., IBM Israel, 
Technion City, Haifa 32000, Israel, phone 
972 (4) 296-205, fax 972 (4) 320-894. 

(g^t MVL 92, 22nd Int’l Symp. on Multi- 
vAz ple-Valued Logic, May 27-29, Sendai, 
Japan. Sponsors: IEEE Computer Soc. 
Technical Committee on Multiple-Valued 
Logic, Japan Research Group on Multiple- 
Valued Logic. Contact Tatsuo Higuchi, 
Electronic Eng. Dept., Tohoku Univ., 
Aoba, Aramaki, Sendai 980, Japan, phone 
81 (022) 222-1800, fax 81 (022) 263-9406, 
e-mail thiguchi@higuchi.ecei.tohoku.ac.jp; 
or S.B. Silio, Electrical Eng. Dept., Univ. 
of Maryland, College Park, MD 20742, 
phone (301) 454-6839, fax (301) 454-1837, 
e-mail silio@eng.umd.edu. 

Symp. on Assessment of Quality 
viz Software Development Tools, May 
27-29, New Orleans. Sponsor: Tulane 
Univ. Contact July Lee, IBM, 1000 NW 
51st. St., Boca Raton, FL 33432, phone 
(407) 982-1048; or Ez Nahouraii, IBM 
(798/089), 6321 San Ignacio Ave., San Jose, 
CA 95119, phone (408) 281-5741, e-mail 
eznah@stlvm7.iinusl.ibm.com. 


June 1992 

|£f)\ FGCS 92, Int’l Conf. on Fifth-Gener- 
vAz ation Computer Systems, June 1-5, 

Tokyo. Cosponsors: Information Process¬ 
ing Soc. of Japan et al. Contact Hidehiko 
Tanaka, Univ. of Tokyo, 3-1 Hongo 7- 
chome, Bunkyo-ku, Tokyo 113, Japan, 
phone 81 (33) 3812-2111 ext. 6663, fax 81 
(33) 3818-5706. 

^ DAC 92, 29th IEEE/ACM Design 
NAz Automation Conf., June 8-12, Ana¬ 
heim, Calif. Contact DAC 92, MP Associ¬ 
ates, 7490 Clubhouse Rd., Boulder, CO 
80301, phone (303) 530-4333; or Dan 
Schweikert, Cadence Design Systems, 555 
River Oaks Pkwy., Bldg. 4, San Jose, CA 
95132, phone (408) 944-7297, e-mail dan® 
cadence.com. 
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BOOK REVIEWS 


Editor: Alan Kaminsky, Rochester Institute of Technology, PO Box 9887, Rochester, NY 14623-0887 
(716) 475-5255; Internet ark@cs.rit.edu;Bitnet arkics@ritvax. 


Computers Under Attack: Intruders, Worms, and Viruses 

Peter J. Denning, ed. (Addison-Wesley, Reading, Mass., 1990, 554 pp., $20.50) 


The siege is on! Computer systems 
today are increasingly subject to at¬ 
tack from a variety of sources. Net¬ 
works and personal computers are 
among the targets. Industry, govern¬ 
ment, academe, and private citizens 
are the victims. What are the threats? 
Who would perpetrate a crime against 
a machine? What can be done to mini¬ 
mize or prevent damage to valuable 
data and equipment? 

Computers Under Attack answers 
these and other questions in an anthol¬ 
ogy of 40 articles, reports, and inter¬ 
views grouped into six areas of interest: 

• worldwide network of computers; 

• intruders; 

• worms; 

• viruses; 

• countercultures; and 

• social, legal, and ethical implica- 

Denning introduces each section with 


a brief commentary that gives histori¬ 
cal context for the material. In addi¬ 
tion, the book includes references and 
a thorough index. 

It is intended to seem like a conver¬ 
sation among individuals interested in 
the well-being of computers and relat¬ 
ed systems worldwide. As a result, 
you can read it from front to back or 
simply start “listening” at any point. 

The material includes security 
methods and lessons learned. Readers 
less familiar with security issues will 
gain valuable insight into the work¬ 
ings of expansive computer networks. 
They will be amazed at how much ter¬ 
ritory these networks cover and dis¬ 
mayed at how many ways there are to 
break through network security fea¬ 
tures or disrupt computer system op¬ 
erations. They will discover the world 
of computer espionage, cyberpunks, 
worms, and viruses. 

Readers with prior exposure to this 


world will benefit from stimulating 
discussions of measures to curtail the 
rise in computer crime. Topics range 
from laws that protect against unau¬ 
thorized intrusion to methods that 
network administrators can employ to 
reduce risks to their systems and data. 

Although most of the articles have 
been previously published, this book 
is not a mere rehash of ideas or a lay¬ 
man’s treatise on computer security. 
Rather, it is a “state of the computer 
age” address, giving equal treatment 
to both technical and social issues. 

Computers Under Attack will make 
an excellent addition to any computer 
professional’s library. It will also serve 
well as a text for computer ethics or 
security courses and as a starting 
point for anyone interested in further 
research on this subject. 

Richard W. Miller 

M Division, US Navy 


Mathematical Foundations of Computer Science, Volume 1 

Peter A. Fejer and Dan A. Simovici (Springer-Verlag, New York, 1991, 425 pp., $35) 


There are at present two extreme 
schools of thought regarding the use 
of mathematical methods in computer 
science. One school, the rigorists, be¬ 
lieves that we do not use them enough 
(for example, Edsger Dijkstra, the 
major prophet, and David Gries, a 
disciple). In support of this opinion, 
they cite complaints about software 
quality. The other school believes that 
past applications show the poverty of 
the rigorous approach. They believe a 
completely different, almost antirigor- 
ist, approach is needed instead. 

This book is obviously from the first 
school. Both authors are in depart¬ 
ments of mathematics and computer 
science, and they have written the ar¬ 
chetypal book in the mathematical 
style. The reader gets a minimum of 
motivation and a maximum of defini¬ 
tion, theorepi, proof, corollary, proof, 
definition, etc., along with strictly 


mathematical examples illustrating 
various points. To get a sense of the 
book, consider Section 4.7: 


Def. 4.7.3 9 

Thm. 4.7.4 10 
Cor. 4.7.5 7 

Cor. 4.7.6 14 
Def. 4.7.9 6 

Def. 4.7.13 2 
Def. 4.7.14 5 
Def. 4.7.15 7 
Def. 4.7.16 6 
Thm. 4.7.17 2 
Thm. 4.7.18 2 
Thm. 4.7.19 8 
Def. 4.7.20 9 
Thm. 4.7.21 10 


lines of print 

lines to state theorem 

lines to state corollary 

lines 

lines 

lines 

lines 

lines 

lines 

lines 

lines 

lines 

lines 

lines 


When you consider the number of lines 
of print, plus the time and effort it can 
take to uncover their meaning, you can 
see what is needed to read the book. 

Moreover, the ratio of definitions to 


theorems makes you wonder if this is 
a sane field. Indeed, I have been spec¬ 
ulating on the underlying nature of a 
book (or field of thinking) that takes 
so much space merely to define and 
state theorems. Obviously, including a 
lot of detail in a definition allows a 
shorter statement of the theorem. 
Further, complexity of definitions and 
theorem statements must come ulti¬ 
mately from the complexity of the de¬ 
tails in the proofs. Thus, as presented 
in this book, the computing field is a 
sea of almost infinite detail. As a re¬ 
sult, the theorems are rarely beautiful. 
I feel that this is an example of the ba¬ 
roque development that occasionally 
occurs in mathematics. 

The authors clearly favor the disci¬ 
pline of proving that a program is cor¬ 
rect. (Their opponents favor the care¬ 
ful testing of a program to prove that 
it is wrong, followed by fixing the er- 
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rors.) At first, the authors’ approach 
seems good to anyone trained, as I 
was, in pure mathematics; but my ex¬ 
periences with it are not encouraging. 
My first big disappointment occurred 
when Dijkstra visited Bell Laborato¬ 
ries and gave a presentation where he 
“proved” the correctness of a program 
that computed binomial coefficients. 

In the questions afterward, someone 
asked, “What about overflow?” An¬ 
swer: “We do not discuss that.” 1 

Unfortunately, all too many pub¬ 
lished proofs that a program is correct 
have been shown to contain errors. 
And so it is with this book. I came 
across a “quicksort” program (not in 
the index, but it appears on page 192), 
that I noticed would not necessarily 
run, despite the extensive proof that it 
would. As often happens, the authors 
neglected the possible lists of zero 
length in the recursive step. I have no 
idea how many more of the “proved” 
programs are faulty or if I hit the only 
one, but this illustrates a general point 
from mathematics; namely, theorems 
are really not proved! 

A knowledgeable mathematician 
observed that most new t heorems are 
true but the proo fs forT henLar e false. 
for generations, we Eavepatched up 
old proofs of Euler, Gauss, and others 
less famous; and we expect future 
generations to patch up proofs for our 
theorems. The myth that there is ab¬ 
solute, ultimate rigor in mathematics 
goes on despite evidence to the con¬ 
trary. Why do people believe that if 
we are rigorous enough, we can get 
completely reliable programs? Wish¬ 
ful thinking only! 

This volume covers elementary set 
theory, relations and functions, par¬ 
tially ordered sets, induction, and enu¬ 
merability and diagonalization. The 
quality of writing is often poor, be¬ 
yond the usual difficulties of “mathe- 
maticalese.” But in fairness, the au¬ 
thors have chosen topics that are 
indeed messy, and they do include nu¬ 
merous examples and exercises that 
help after you fight your way through 
the definition or theorem. 

I once argued with Donald Knuth 
that what his books contained was not 
appropriate for computer scientists, 
and I finally got him to state, “The 
books contain what has interested 
me.” In the same way, I think this 
book may be interesting for the math¬ 
ematically inclined, logic-oriented re¬ 
searcher who wants to publish papers, 
but I cannot bring myself to believe it 
appropriate for engineers. 

( R. W. Hamming 
v Naval Postgraduate School ■, 


Ada in Distributed Real-Time Systems 

Kjell Nielsen (McGraw-Hill, New York, 1990, 414 pp„ $49.95) 


The goal of this book is to describe 
a methodology for designing and 
programming distributed real-time 
applications using the Ada language. 
The author defines distributed real¬ 
time systems in this book as sets of 
concurrent processes that communi¬ 
cate (1) with each other through a 
combination of message passing, sig¬ 
naling, and shared data, and (2) with 
the environment through hardware 
interfaces supported by device driv¬ 
ers. 

The proposed methodology em¬ 
phasizes paradigms for mapping pro¬ 
grams onto physical nodes (logical- 
to-physical mapping), and the book 
begins with background discussions 
to support it. First, it describes three 
classes of architectures: multicom¬ 
puter systems (networks of comput¬ 
ers), multiprocessor systems (parallel 
processors), and multi-microproces¬ 
sor systems. Only the latter class is 
relevant to the design methodology 
presented in this book. I saw no 
good reason to include the others 
here. 

I could say the same about the de¬ 
scriptions of network and bus inter¬ 
connections. Why include an elemen¬ 
tary discussion of network topologies, 
which can be found in virtually every 
book on distributed systems? On the 
other hand, the discussion of ad¬ 
vanced backplane buses is a nice sur¬ 
prise — the first introduction to this 
topic I’ve seen m a book dealing pri¬ 
marily with software. Standard bus 
architectures tend to dominate real¬ 
time systems, not supercomputer ar¬ 
chitectures or even networks (except 
for local area networks). Extending 
the background in this direction 
would therefore be welcome. 

The background for support envi¬ 
ronments ranges from operating sys¬ 
tem kernels to programming lan¬ 
guages and development tools. I 
found the discussion of kernel primi¬ 
tives too commercially oriented; it 
lists real-time operating systems cur¬ 
rently on the market, rather than de¬ 
scribing important primitives and 
what makes them useful. The over¬ 
view of basic programming-language 
constructs for distributed systems 
(Ada, Concurrent C, and Occam) is 
satisfactory. 

The discussion of development 
tools — a crucial issue for program¬ 
ming distributed real-time applica¬ 
tions — is extremely interesting. Al¬ 


though debugging, linking, loading, 
run-time support, etc., are given equal 
attention, the stress is on the key 
problem of specifying virtual nodes 
and mapping them onto properly se¬ 
lected physical nodes. 

Nielsen addresses the lack of con¬ 
structs in Ada for distributing tasks 
among processors. He mentions exist¬ 
ing techniques to overcome this diffi¬ 
culty but notes that none have yet 
been implemented commercially. He 
therefore develops his own design 
methodology. It is an extension of the 
approach for single-processor systems 
that Nielsen and coauthor Ken Shu¬ 
mate described in Designing Large 
Real-Time Systems With Ada 
(McGraw-Hill, 1988). This methodol¬ 
ogy first determines the process ab¬ 
straction that represents a concurrent 
model of the system (expressed as a 
set of cooperating Ada tasks embed¬ 
ded in virtual nodes). Then a set of 
processors is selected and virtual 
nodes are mapped to them in a dis¬ 
tributed configuration. This method¬ 
ology is a “software-first” approach, 
which means that no initial assump¬ 
tions are made about the hardware ar¬ 
chitecture. 

The book includes techniques to 
make this approach feasible. For ex¬ 
ample, it presents a dozen heuristics 
for selectirtg processes and virtual 
nodes, using specifications based on 
dataflow and state-transition dia¬ 
grams. However, the author warns 
that none of these techniques is yet 
commercially available, so potential 
users must implement the underlying 
compilation, linking, and loading ser¬ 
vices. As the author says, “This is no 
simple task in a heterogeneous envi¬ 
ronment.” 

Two interesting case studies illus¬ 
trate the author’s approach. Although 
I have some criticisms, I believe this 
book meets its goal for system design¬ 
ers, application programmers, and 
software engineers currently working 
with distributed real-time systems. It 
also provides good background for 
system programmers building both 
traditionally oriented tools and tools 
aimed at distributed systems. Finally, 
it would be a good choice for a gradu¬ 
ate course on distributed or real-time 
systems, especially one that included 
construction of a development tool. 

Janusz Zalewski 

Southwest Texas State University 


January 1992 
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Editor: Will Tracz, IBM, Federal Sector Division, Mail Drop 0210, Owego, NY 13827 
e-mail tracz@owgvmO.vnet.ibm.com 


Terminology risks with the RISC concept in the risky RISC arena 


Speaking at the International Sym¬ 
posium on Computer Architecture in 
Toronto last May, Yale Patt of the 
University of Michigan said that “one 
good thing about reduced instruction- 
set computers is that the definition of 
the underlying concept keeps chang¬ 
ing. Consequently, the concept will al¬ 
ways be state of the art.” 

Patt’s point was that, since the 
meaning of “RISC” keeps changing, 
the term can be interpreted in a num¬ 
ber of different ways. 

Many complex instruction-set com¬ 
puters (CISCs) are doing extremely 
well on the commercial market. Some 
people have even begun calling them 
“commercially (successful) instruc¬ 
tion-set computers.” A number of so- 
called RISC computers do not share 
this good fortune and might be more 
properly labeled “romantic instruc¬ 
tion-set computers,” whose design is 
sustained more by infatuation than by 
income. 

The designers of these financially 
risky machines do, however, seem to 
broadly agree on two points: 

(1) anything good is (by definition) 
a RISC concept, and 

(2) CISC designs include everything 
not RISC. 

We observe that CISC designs gen¬ 
erally have more highly encoded, 
hence more compact, instruction sets 
than RISC designs. This is because 
CISC architectures result from long¬ 
term collaborative compromises 


“The Open Channel” is exactly 
what the name implies: a forum for 
the free exchange of technical 
ideas. Try to hold your contribu¬ 
tions to one page maximum in the 
final magazine format (about 850 
words). 

We’ll accept anything (short of 
libel or obscenity), so long as it’s 
submitted by a member of the 
IEEE Computer Society. If it’s real¬ 
ly bizarre, we may ask you to get 
another member to cosponsor 
your contribution. 

Send everything to-Will Tracz at 
the address above. 


across many different vendors and 
types of applications, an evolution 
culminating in a “converged instruc¬ 
tion-set computer.” Today, with the 
emergence of a competitive clone chip 
market, CISC is often understood to 
mean “compatible industry standard 
computers,” a rewrite of the older 
form, “clearly Intel’s (most) successful 
computer.” 

RISC computers that are commer¬ 
cially successful rely on complex re¬ 
sources — such as floating-point and 
special-graphics hardware — that 
could fit into a CISC. In this context, 
RISC would mean “resources invent¬ 
ed (to) speed(up) compiled (high- 
level language programs).” 

Another popular interpretation of 
RISC that we hear more and more of¬ 
ten is “realize (maximum functional¬ 
ity) in single cycle.” This definition 
opens the door for all current and fu¬ 
ture superscalar and superpipelined 
machines to be called RISCs, even 
though the basic ideas were first de¬ 
veloped in a CISC mainframe context 
(where we referred to these ideas as 
“pipelining”). 

To help increase sales, companies 
always seem ready to label their new¬ 
est computer a RISC, even if it has 
nothing in common with the early ma¬ 
chinery that helped coin the term. Of 
course, several of these are microcod- 
ed, making some of the early RISC re¬ 
searchers sound like prophets of a re¬ 
written future. 

Some computer researchers take 
their work very seriously and enjoy 
adding “exact science” flavor to their 
definitions. In this style, the basic 
RISC design imperative might be 
written: “A resource should be added 
onto the chip if, and only if, its incor¬ 
poration is justified by its frequency 
of use and does not slow down any of 
the resources already on the chip, 
since they are used more frequently in 
the given application.” 

This implies that designs should be 
based on statistical analysis, rather 
than unsupported intuition. Such a 
scientific approach appeals to comput¬ 
er architects, who like to evaluate 
trade-offs. We feel this is a healthful 
trend that will lead to more accurate 


histories and analyses of computer ar¬ 
chitectures. 

The evolution of RISC practices 
sometimes reminds us of the poor guy 
who became rich. During his days of 
poverty, he did not eat meat (transis¬ 
tors) because he did not have money 
(resources to design large computers 
and make large chips) and was forced 
to become a vegetarian. Now he has 
money, but still doesn’t eat meat be¬ 
cause he believes that meat is not 
healthy; consequently, he remains a 
vegetarian on principle. 

This new rationale may or may not 
stand the test of time and appetite. 
Likewise, we still see architectures 
that reflect the transistor poverty of 
early-1980s RISCs; but in the 1990s, 
these implementations can no longer 
be excused as “very early attempts to 
make a RISC processor.” The reasons 
for increasing or decreasing complexi¬ 
ty or transistor consumption have 
changed with the times: “reality is 
sometimes cruel.” In our analogy, 
RISC designers’ newly acquired taste 
for complexity resembles the overin¬ 
dulgence of the newly rich suffering 
from the “free-food syndrome.” 

Today’s CISC-like RISCs include 
many complex and sophisticated fea¬ 
tures typical of earlier mainframe 
CISC designs. They reminds us of the 
vegetarian whose favorite food is 
roast lamb. Lamb, he claims, being 
nothing more than transformed grass, 
is an excellent vegetarian food. 

To avoid possible misunderstand¬ 
ings, we feel it’s important to stress 
that creating the views expressed here 
required displacing ourselves to get a 
good, long-distance overview of the 
problem. Part of this column was con¬ 
ceptualized in a medieval monastery 
in Serbia. The remaining ideas came 
to us — with help from Milivoje Ale- 
ksic, Milenko Cvetinovic, Walter 
Koenig, and Helmut Weber in both 
settings — during a committee brunch 
at a contemporary resort setting dur¬ 
ing the January 1990 Hawaii Interna¬ 
tional Conference on System Sciences. 

Lee Hoevel, NCR 

Veljko Milutinovic, University 
of Belgrade 
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between computers and communications. For the past 10 years 
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the theory and applications of advanced technology in these 
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Full-Day Tutorials April 1, 1992 

• Digital Image Processing 

• Fault Tolerant Multiprocessor Design 

• VHDL 
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• Hybrid-Architecture Local Area Networks 

• Concepts and Tools for Development of 
Distributed Software 
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• Software Process Assessment 
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Distinguished Speakers 

Prof. Raymond E. Miller, University of 
Maryland, Computer Science Dept., “Basic 
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Mr. Michael A. Kaminski, Jr., Manager of CIM 
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American Express, Advanced Technology 
Group, “The Dynamics of Technology in 
American Business”. 


Technical Sessions in Six Tracks April 2-3, 1992 
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